From eshikafe@REDACTED Sun Mar 1 00:18:16 2015 From: eshikafe@REDACTED (austin aigbe) Date: Sun, 1 Mar 2015 00:18:16 +0100 Subject: [erlang-questions] Unable to access my inets http server from my phone or external PC Message-ID: Hi, I can't seem to access the erlang inets http server (web_server.erl) from my Android phone (using http://:8000) via WiFi However, I am able to access the python based simpleHTTPServer from my Android phone (using http://:8000) via WiFi. How do I make my erlang inets server accessible from an external PC or phone? OS: Windows 7 %----------------------- % web_server.erl %------------------------- -module(web_server). -export([start/0, stop/0]). -define(PORT, 8000). -define(SERVER_NAME, "server1"). -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). start() -> {ok, _} = inets:start(httpd, [{port, ?PORT}, {server_name,?SERVER_NAME}, {server_root,?ROOT}, {document_root,?ROOT}, {bind_address,{127,0,0,1}}, {directory_index,["index.html"]}, {server_tokens, full}]). stop() -> [{_,_},{_,P2}] = inets:services(), ok = inets:stop(httpd, P2). BR, Austin -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonard.boyce@REDACTED Sun Mar 1 01:26:26 2015 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Sat, 28 Feb 2015 19:26:26 -0500 Subject: [erlang-questions] Unable to access my inets http server from my phone or external PC In-Reply-To: References: Message-ID: Removing the bind_address or set it to a non-localhost IP which is bound to your machine should sort it out. Leonard On Feb 28, 2015 6:19 PM, "austin aigbe" wrote: > Hi, > > I can't seem to access the erlang inets http server (web_server.erl) from > my Android phone (using http://:8000) via WiFi > > However, I am able to access the python based simpleHTTPServer from my > Android phone (using http://:8000) via WiFi. > > How do I make my erlang inets server accessible from an external PC or > phone? > > OS: Windows 7 > > %----------------------- > % web_server.erl > %------------------------- > -module(web_server). > -export([start/0, stop/0]). > > -define(PORT, 8000). > -define(SERVER_NAME, "server1"). > -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). > > start() -> > {ok, _} = inets:start(httpd, > [{port, ?PORT}, > {server_name,?SERVER_NAME}, > {server_root,?ROOT}, > {document_root,?ROOT}, > {bind_address,{127,0,0,1}}, > {directory_index,["index.html"]}, > {server_tokens, full}]). > > stop() -> > [{_,_},{_,P2}] = inets:services(), > ok = inets:stop(httpd, P2). > > BR, > Austin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eshikafe@REDACTED Sun Mar 1 02:54:57 2015 From: eshikafe@REDACTED (austin aigbe) Date: Sun, 1 Mar 2015 02:54:57 +0100 Subject: [erlang-questions] Unable to access my inets http server from my phone or external PC In-Reply-To: References: Message-ID: Still the same experience. I still can't connect. What could be wrong? python -m SimpleHTTPServer works well and this implies it's not my network configuration but an application issue. In this case my web_server.erl application. So what am I doing incorrectly? On Sun, Mar 1, 2015 at 1:26 AM, Leonard Boyce wrote: > Removing the bind_address or set it to a non-localhost IP which is bound > to your machine should sort it out. > > Leonard > On Feb 28, 2015 6:19 PM, "austin aigbe" wrote: > >> Hi, >> >> I can't seem to access the erlang inets http server (web_server.erl) from >> my Android phone (using http://:8000) via WiFi >> >> However, I am able to access the python based simpleHTTPServer from my >> Android phone (using http://:8000) via WiFi. >> >> How do I make my erlang inets server accessible from an external PC or >> phone? >> >> OS: Windows 7 >> >> %----------------------- >> % web_server.erl >> %------------------------- >> -module(web_server). >> -export([start/0, stop/0]). >> >> -define(PORT, 8000). >> -define(SERVER_NAME, "server1"). >> -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). >> >> start() -> >> {ok, _} = inets:start(httpd, >> [{port, ?PORT}, >> {server_name,?SERVER_NAME}, >> {server_root,?ROOT}, >> {document_root,?ROOT}, >> {bind_address,{127,0,0,1}}, >> {directory_index,["index.html"]}, >> {server_tokens, full}]). >> >> stop() -> >> [{_,_},{_,P2}] = inets:services(), >> ok = inets:stop(httpd, P2). >> >> BR, >> Austin >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sun Mar 1 12:19:56 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 1 Mar 2015 15:19:56 +0400 Subject: [erlang-questions] memsup bug? In-Reply-To: References: Message-ID: Yes, this becomes very often bug: 2015-03-01 06:11:29 =CRASH REPORT==== crasher: initial call: memsup:init/1 pid: <0.234.0> registered_name: memsup exception exit: {{badarg,[{erlang,cancel_timer,[undefined],[]},{memsup,handle_info,2,[{file,"memsup.erl"},{line,471}]},{gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,593}]},{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,659}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]},[{gen_server,terminate,7,[{file,"gen_server.erl"},{line,804}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]} ancestors: [os_mon_sup,<0.231.0>] messages: [] links: [<0.232.0>,<0.235.0>] dictionary: [{system_memory_high_watermark,set}] trap_exit: true status: running heap_size: 2586 stack_size: 27 reductions: 12153 neighbours: I can fix memsup from all these erlang:cancel_timer(undefined), but I need to know if this patch is welcome? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom@REDACTED Sun Mar 1 15:35:15 2015 From: tom@REDACTED (Tom van Neerijnen) Date: Sun, 1 Mar 2015 14:35:15 +0000 Subject: [erlang-questions] Unable to access my inets http server from my phone or external PC In-Reply-To: References: Message-ID: bind_address,{127,0,0,1} should be bind_address,{0,0,0,0}. 127.0.0.1 is the loopback interface and only receives connections from the same host which is why you can't connect from other devices. On Sun, Mar 1, 2015 at 1:54 AM, austin aigbe wrote: > Still the same experience. I still can't connect. > What could be wrong? > > python -m SimpleHTTPServer works well and this implies it's not my network > configuration but an application issue. In this case my web_server.erl > application. So what am I doing incorrectly? > > On Sun, Mar 1, 2015 at 1:26 AM, Leonard Boyce < > leonard.boyce@REDACTED> wrote: > >> Removing the bind_address or set it to a non-localhost IP which is bound >> to your machine should sort it out. >> >> Leonard >> On Feb 28, 2015 6:19 PM, "austin aigbe" wrote: >> >>> Hi, >>> >>> I can't seem to access the erlang inets http server (web_server.erl) >>> from my Android phone (using http://:8000) via WiFi >>> >>> However, I am able to access the python based simpleHTTPServer from my >>> Android phone (using http://:8000) via WiFi. >>> >>> How do I make my erlang inets server accessible from an external PC or >>> phone? >>> >>> OS: Windows 7 >>> >>> %----------------------- >>> % web_server.erl >>> %------------------------- >>> -module(web_server). >>> -export([start/0, stop/0]). >>> >>> -define(PORT, 8000). >>> -define(SERVER_NAME, "server1"). >>> -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). >>> >>> start() -> >>> {ok, _} = inets:start(httpd, >>> [{port, ?PORT}, >>> {server_name,?SERVER_NAME}, >>> {server_root,?ROOT}, >>> {document_root,?ROOT}, >>> {bind_address,{127,0,0,1}}, >>> {directory_index,["index.html"]}, >>> {server_tokens, full}]). >>> >>> stop() -> >>> [{_,_},{_,P2}] = inets:services(), >>> ok = inets:stop(httpd, P2). >>> >>> BR, >>> Austin >>> >>> _______________________________________________ >>> 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 > > -- Thomas van Neerijnen +4477 1709 7670 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Sun Mar 1 23:54:01 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 2 Mar 2015 11:54:01 +1300 Subject: [erlang-questions] Improve errors for maps In-Reply-To: References: Message-ID: <152BAB22-736D-4994-ACC0-C4046F544D93@cs.otago.ac.nz> On 28/02/2015, at 6:57 am, Anthony Ramine wrote: > Could we some day start a discussion on the state of error reasons in Erlang/OTP? > > Some things are very clueless like discrepancies between the shell and compiled code ([ X || X <- [1], _ = foo ]), non-obvious discrepancies between some filters (replace _ = foo by just foo in previous example) or even plain useless error reasons like {badrecord,foo}. > > Could that be gradually improved on a large timescale? +1 When we (ok, I) added exceptions to Quintus Prolog, we (ok, I) developed a classification of errors. To put this into more-or-less Erlang terms: - Failures : the outside world is not as we thought it would be (missing file &c). It's not the program but the world needs fixing. - Errors : the programmer has clearly stuffed up. The program needs fixing. - Faults : the programmer asked for something potentially reasonable, but the system could not do it, either because of a capacity issue or because of an error in the system. The system needs fixing. Within this, there was a finer classification, like - type errors : an argument has the wrong type - domain errors : e.g. division by 0, sqrt(-1), tail of an empty list, &c - syntax errors - existence errors : you tried to operate on some 'object' using a well formed name but there is no such object, e.g., calling a non-existent function - permission errors : the thing you tried to operate on exists but you aren't allowed to do that The idea behind the classification was that the programmer doesn't just need to know "what happened" but "what do I DO about it?" One major aim was to make it *predictable*: if you knew what a built in operation did, you should be able to predict all the error terms it could report. This classification was simplified and adopted in the ISO Prolog standard. It proved necessary to revise it a bit, but the basic idea of making the possible errors predictable from the meaning proved sound. The next step was a boring slog through all the code where we (ok I) converted all error reporting to the new structured exception terms, sometimes rewriting things to try to report errors earlier or clearer, and above all to report all errors as if they had come directly from the procedure the programmer had called, not from deep in the implementation. It's one of those things you don't actually _enjoy_ but end up proud of. There's a marked contrast between ISO Prolog and ANSI Smalltalk. Prolog's exception handling system is simpler than Java's; Smalltalk's is vastly more elaborate. But the ANSI Smalltalk standard has practically nothing to say about *which* exceptions get raised, so there is nothing a *portable* Smalltalk program can actually *do* with exception handling, except to catch divide by zero. Again, while Prolog's exception handling is simpler than Java's, if you are using a 3rd party library you have no way of predicting what exceptions they will raise, whereas in Prolog there are clear guidelines. Of course, with the Erlang philosophy of error handling being "log it and crash", there's not so very much that you *want* the exception system to do. Even so, having *informative* exception terms that follow a "pattern language" for exception terms so that people writing error signalling code have guidelines to follow can make it easier to tell what an exception might mean. From eajam@REDACTED Mon Mar 2 00:17:22 2015 From: eajam@REDACTED (Alex Alvarez) Date: Sun, 1 Mar 2015 18:17:22 -0500 Subject: [erlang-questions] Yaws 1.99 In-Reply-To: <5473B90F.9080309@hyber.org> References: <5473B90F.9080309@hyber.org> Message-ID: Sorry if this has already been asked/answered, but could there be a PGP/GPG signature set for each new version of Yaws? Thanks, Alex On 11/24/2014 06:02 PM, Claes Wikstrom wrote: > > Folks, > > Yaws 1.99 is out. We're like wine, maturing. Getting better !! > > Tested release at > > http://yaws.hyber.org/download/yaws-1.99.tar.gz and > http://yaws.hyber.org/download/Yaws-1.99-windows-installer.exe > > Code at https://github.com/klacke/yaws > > Thanks everyone for contributing. Community > effort at it's best !! > > /klacke/steve/christopher > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eshikafe@REDACTED Sun Mar 1 22:20:38 2015 From: eshikafe@REDACTED (austin aigbe) Date: Sun, 1 Mar 2015 22:20:38 +0100 Subject: [erlang-questions] Unable to access my inets http server from my phone or external PC In-Reply-To: References: Message-ID: Thanks Thomas. Changing the bind_address to 0.0.0.0 solved the issue. Surprisingly, the python server is also using 0.0.0.0 and I did not even notice it. C:\Users\eausaig>python -m SimpleHTTPServer Serving HTTP on *0.0.0.0* port 8000 ... Working version: -module(web_server). -export([start/0, stop/0]). -define(PORT, 8000). -define(SERVER_NAME, "server1"). -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). start() -> inets:start(), {ok, _} = inets:start(httpd, [{port, ?PORT}, {server_name,?SERVER_NAME}, {server_root,?ROOT}, {document_root,?ROOT}, {bind_address,{*0,0,0,0*}}, {directory_index,["index.html"]}, {server_tokens, full}]). stop() -> [{_,_},{_,P2}] = inets:services(), ok = inets:stop(httpd, P2). BR, Austin bind_address,{127,0,0,1} should be bind_address,{0,0,0,0}. 127.0.0.1 is the loopback interface and only receives connections from the same host which is why you can't connect from other devices. -- Thomas van Neerijnen +4477 1709 7670 On Sun, Mar 1, 2015 at 1:26 AM, Leonard Boyce wrote: > Removing the bind_address or set it to a non-localhost IP which is bound > to your machine should sort it out. > > Leonard > On Feb 28, 2015 6:19 PM, "austin aigbe" wrote: > >> Hi, >> >> I can't seem to access the erlang inets http server (web_server.erl) from >> my Android phone (using http://:8000) via WiFi >> >> However, I am able to access the python based simpleHTTPServer from my >> Android phone (using http://:8000) via WiFi. >> >> How do I make my erlang inets server accessible from an external PC or >> phone? >> >> OS: Windows 7 >> >> %----------------------- >> % web_server.erl >> %------------------------- >> -module(web_server). >> -export([start/0, stop/0]). >> >> -define(PORT, 8000). >> -define(SERVER_NAME, "server1"). >> -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). >> >> start() -> >> {ok, _} = inets:start(httpd, >> [{port, ?PORT}, >> {server_name,?SERVER_NAME}, >> {server_root,?ROOT}, >> {document_root,?ROOT}, >> {bind_address,{127,0,0,1}}, >> {directory_index,["index.html"]}, >> {server_tokens, full}]). >> >> stop() -> >> [{_,_},{_,P2}] = inets:services(), >> ok = inets:stop(httpd, P2). >> >> BR, >> Austin >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Mon Mar 2 18:00:01 2015 From: sean@REDACTED (Functional Jobs) Date: Mon, 2 Mar 2015 12:00:01 -0500 Subject: [erlang-questions] New Functional Programming Job Opportunities Message-ID: <54f497131e89f@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Senior Software Engineer at McGraw-Hill Education http://functionaljobs.com/jobs/8787-senior-software-engineer-at-mcgraw-hill-education Cheers, Sean Murphy FunctionalJobs.com From nyarly@REDACTED Mon Mar 2 20:20:40 2015 From: nyarly@REDACTED (Judson Lester) Date: Mon, 02 Mar 2015 19:20:40 +0000 Subject: [erlang-questions] Design patterns? Message-ID: As I'm becoming more comfortable and proficient in Erlang, I'm finding there there are interesting patterns that begin to emerge that I'm not sure I've seen elsewhere. I'm wondering if there's a collection somewhere, maybe c2 style? One example is a complicated data processing: I've started creating a special purpose record and dispatching based on its fields. That includes short-circuiting on errors, constructing syntheses from simpler data, etc. Since I've stumbled onto it, I've been really liking how it can bring the full force of pattern matching to complex processing. I do worry that it's a bit of a smell though. If the processing can be simplified, that might be better, but it's better, imo, than a long ladder of maybe_compute_other_thing style functions. And an open question (for me): when to use case/if versus function heads? Roughly, I've been using cases to reformat the returns of a function call, but the decision trips me up every time. Judson -------------- next part -------------- An HTML attachment was scrubbed... URL: From alttagil@REDACTED Mon Mar 2 21:46:40 2015 From: alttagil@REDACTED (Alex Hudich) Date: Mon, 2 Mar 2015 23:46:40 +0300 Subject: [erlang-questions] {tls_alert,"handshake failure"} Message-ID: Hi I?ve got some strange errors when I try to make SSL connection to a web-site with peer verification on. Here?s an example: I?ve downloaded PEM certificates from https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt Then I start erl and run a command ssl:start(). Then I try to connect somewhere (I renamed ca-bundle.crt file to a cacert.pem): 2> ssl:connect( "t.ileads.ru", 443, [{verify,verify_peer},{cacertfile,"cacert.pem"}]). =ERROR REPORT==== 2-Mar-2015::23:32:15 === SSL: certify: ssl_handshake.erl:1403:Fatal error: handshake failure {error,{tls_alert,"handshake failure"}} Without peer verification everything went ok. What?s wrong? Or maybe I do something wrong? -- cul8er, Alex. From giannis.pin@REDACTED Mon Mar 2 23:54:20 2015 From: giannis.pin@REDACTED (Ioannis Pinakoulakis) Date: Mon, 2 Mar 2015 23:54:20 +0100 Subject: [erlang-questions] Unable to access my inets http server from my phone or external PC In-Reply-To: References: Message-ID: <892D0F36-AD94-4FA1-B957-653CF777A142@gmail.com> Basically, 0.0.0.0 means that it will bind on any available netwprk interface on the local machine. Visiting the link you will find a more complete explanation why this happens. http://serverfault.com/q/78048 /Ioannis 1 mar 2015, 22:20, ?/? austin aigbe ??????: > Thanks Thomas. > > Changing the bind_address to 0.0.0.0 solved the issue. > > Surprisingly, the python server is also using 0.0.0.0 and I did not even notice it. > > C:\Users\eausaig>python -m SimpleHTTPServer > Serving HTTP on 0.0.0.0 port 8000 ... > > > Working version: > > -module(web_server). > -export([start/0, stop/0]). > > -define(PORT, 8000). > -define(SERVER_NAME, "server1"). > -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). > > start() -> > inets:start(), > {ok, _} = inets:start(httpd, > [{port, ?PORT}, > {server_name,?SERVER_NAME}, > {server_root,?ROOT}, > {document_root,?ROOT}, > {bind_address,{0,0,0,0}}, > {directory_index,["index.html"]}, > {server_tokens, full}]). > > stop() -> > [{_,_},{_,P2}] = inets:services(), > ok = inets:stop(httpd, P2). > > BR, > Austin > > > > bind_address,{127,0,0,1} should be bind_address,{0,0,0,0}. 127.0.0.1 is the loopback interface and only receives connections from the same host which is why you can't connect from other devices. > > -- > Thomas van Neerijnen > +4477 1709 7670 > >> On Sun, Mar 1, 2015 at 1:26 AM, Leonard Boyce wrote: >> Removing the bind_address or set it to a non-localhost IP which is bound to your machine should sort it out. >> >> Leonard >> >>> On Feb 28, 2015 6:19 PM, "austin aigbe" wrote: >>> Hi, >>> >>> I can't seem to access the erlang inets http server (web_server.erl) from my Android phone (using http://:8000) via WiFi >>> >>> However, I am able to access the python based simpleHTTPServer from my Android phone (using http://:8000) via WiFi. >>> >>> How do I make my erlang inets server accessible from an external PC or phone? >>> >>> OS: Windows 7 >>> >>> %----------------------- >>> % web_server.erl >>> %------------------------- >>> -module(web_server). >>> -export([start/0, stop/0]). >>> >>> -define(PORT, 8000). >>> -define(SERVER_NAME, "server1"). >>> -define(ROOT,"C:/Users/eausaig/Desktop/web_server"). >>> >>> start() -> >>> {ok, _} = inets:start(httpd, >>> [{port, ?PORT}, >>> {server_name,?SERVER_NAME}, >>> {server_root,?ROOT}, >>> {document_root,?ROOT}, >>> {bind_address,{127,0,0,1}}, >>> {directory_index,["index.html"]}, >>> {server_tokens, full}]). >>> >>> stop() -> >>> [{_,_},{_,P2}] = inets:services(), >>> ok = inets:stop(httpd, P2). >>> >>> BR, >>> Austin >>> >>> _______________________________________________ >>> 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 frederic.bonfanti@REDACTED Tue Mar 3 00:00:58 2015 From: frederic.bonfanti@REDACTED (Frederic Bonfanti) Date: Tue, 3 Mar 2015 00:00:58 +0100 Subject: [erlang-questions] SNMP Development Toolkit Message-ID: Hi, I have been playing around with snmp but this giving me a hard time... here is the error I get: > snmp_ex2_simple_standard_test:start({192,168,1,1}). snmpm:snmpm:mk_target_name(snmpUDPDomain, {{192,168,1,1},161}, [{community, "public"}]) -> "192.168.1.1:161-v1". Command 1 (get-next [1,1]): error {command_failed,not_found} ... SNMP works fine from both Mac OS X / snmpget and remote agent perspectives... Only erlang SNMP toolkit refuses to operate properly. Any hint appreciated +F -------------- next part -------------- An HTML attachment was scrubbed... URL: From wgwi@REDACTED Tue Mar 3 07:30:33 2015 From: wgwi@REDACTED (=?UTF-8?B?546L54Kc?=) Date: Tue, 03 Mar 2015 14:30:33 +0800 Subject: [erlang-questions] SNMP Development Toolkit In-Reply-To: References: Message-ID: <54F55509.6090604@sxu.edu.cn> Last month I try to use Erlang snmp package to solve SNMP get and set problem, but It's really hard. so I turned to Golang to solve it. With the github.com/cdevr/WapSNMP package, You will find it's fast, easy and stable. ? 2015/3/3 7:00, Frederic Bonfanti ??: > Hi, > > I have been playing around with snmp but this giving me a hard time... > > here is the error I get: > > > snmp_ex2_simple_standard_test:start({192,168,1,1}). > snmpm:snmpm:mk_target_name(snmpUDPDomain, {{192,168,1,1},161}, > [{community, "public"}]) -> "192.168.1.1:161-v1". > > Command 1 (get-next [1,1]): error > {command_failed,not_found} > ... > > > SNMP works fine from both Mac OS X / snmpget and remote agent > perspectives... Only erlang SNMP toolkit refuses to operate properly. > > Any hint appreciated > > +F > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ates@REDACTED Tue Mar 3 08:34:27 2015 From: ates@REDACTED (Artem Teslenko) Date: Tue, 03 Mar 2015 09:34:27 +0200 Subject: [erlang-questions] SNMP Development Toolkit In-Reply-To: References: Message-ID: <54F56403.7010503@ipv6.dp.ua> Hello, Try this: -module(snmp_test). -compile(export_all). start() -> snmpm:start(), snmpm:register_user(?MODULE, snmpm_user_default, undefined). t() -> Opts = [ {engine_id, "test"}, {community, "public"}, {version, v2}, {address, {127,0,0,1}} ], ok = snmpm:register_agent(?MODULE, "test123", Opts), Reply = snmpm:sync_get(?MODULE, "test123", [[1,3,6,1,2,1,1,1,0]]), ok = snmpm:unregister_agent(?MODULE, "test123"), Reply. $ erlc snmp_test.erl $ erl Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.3 (abort with ^G) 1> snmp_test:start(). ok 2> snmp_test:t(). {ok,{noError,0, [{varbind,[1,3,6,1,2,1,1,1,0], 'OCTET STRING', "Linux ates-desktop 3.13.0-46-generic #76-Ubuntu SMP Thu Feb 26 18:52:13 UTC 2015 x86_64", 1}]}, 4993} 3> snmp_test:t(). {ok,{noError,0, [{varbind,[1,3,6,1,2,1,1,1,0], 'OCTET STRING', "Linux ates-desktop 3.13.0-46-generic #76-Ubuntu SMP Thu Feb 26 18:52:13 UTC 2015 x86_64", 1}]}, 4999} On 03/03/2015 01:00 AM, Frederic Bonfanti wrote: > Hi, > > I have been playing around with snmp but this giving me a hard time... > > here is the error I get: > > > snmp_ex2_simple_standard_test:start({192,168,1,1}). > snmpm:snmpm:mk_target_name(snmpUDPDomain, {{192,168,1,1},161}, > [{community, "public"}]) -> "192.168.1.1:161-v1". > > Command 1 (get-next [1,1]): error > {command_failed,not_found} > ... > > > SNMP works fine from both Mac OS X / snmpget and remote agent > perspectives... Only erlang SNMP toolkit refuses to operate properly. > > Any hint appreciated > > +F > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From gguthrie@REDACTED Tue Mar 3 09:30:32 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Tue, 3 Mar 2015 08:30:32 +0000 Subject: [erlang-questions] Design patterns? In-Reply-To: References: Message-ID: <54f5712a.d295b40a.2a9a.6551@mx.google.com> Generally function heads are 'better' than cases, particularly if there are a lot of them... This email would be easier to answer if there was some code so people could outline options... G -----Original Message----- From: "Judson Lester" Sent: ?02/?03/?2015 19:20 To: "Erlang Users' List" Subject: [erlang-questions] Design patterns? As I'm becoming more comfortable and proficient in Erlang, I'm finding there there are interesting patterns that begin to emerge that I'm not sure I've seen elsewhere. I'm wondering if there's a collection somewhere, maybe c2 style? One example is a complicated data processing: I've started creating a special purpose record and dispatching based on its fields. That includes short-circuiting on errors, constructing syntheses from simpler data, etc. Since I've stumbled onto it, I've been really liking how it can bring the full force of pattern matching to complex processing. I do worry that it's a bit of a smell though. If the processing can be simplified, that might be better, but it's better, imo, than a long ladder of maybe_compute_other_thing style functions. And an open question (for me): when to use case/if versus function heads? Roughly, I've been using cases to reformat the returns of a function call, but the decision trips me up every time. Judson -------------- next part -------------- An HTML attachment was scrubbed... URL: From zkessin@REDACTED Tue Mar 3 12:07:38 2015 From: zkessin@REDACTED (Zachary Kessin) Date: Tue, 03 Mar 2015 13:07:38 +0200 Subject: [erlang-questions] New Erlang EBook Message-ID: <54F595FA.9060006@gmail.com> Hi everyone, I have just put out a new Ebook on Using QuickCheck on Erlang. It covers all three major erlang QuickCheck versions (Quviq, PropEr, and Triq). and will take you from your first property to being a QuickCheck master. Right now it is in Early Release. The content is being developed and it should be finished by Erlang Factory SF. If you buy it today you will get all the updates as I work on it http://www.erlang-quickcheck-book.com/ -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Tue Mar 3 14:12:01 2015 From: radek@REDACTED (Rad Gruchalski) Date: Tue, 3 Mar 2015 14:12:01 +0100 Subject: [erlang-questions] Design patterns? In-Reply-To: References: Message-ID: <6940ECA3FEC745FC91F362F82ED399C7@gruchalski.com> There?s an interesting github repository: https://github.com/inaka/erlang_guidelines. Some of these should be taken with a grain of salt. Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) +4917685656526 Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Monday, 2 March 2015 at 20:20, Judson Lester wrote: > As I'm becoming more comfortable and proficient in Erlang, I'm finding there there are interesting patterns that begin to emerge that I'm not sure I've seen elsewhere. I'm wondering if there's a collection somewhere, maybe c2 style? > > One example is a complicated data processing: I've started creating a special purpose record and dispatching based on its fields. That includes short-circuiting on errors, constructing syntheses from simpler data, etc. Since I've stumbled onto it, I've been really liking how it can bring the full force of pattern matching to complex processing. I do worry that it's a bit of a smell though. If the processing can be simplified, that might be better, but it's better, imo, than a long ladder of maybe_compute_other_thing style functions. > > And an open question (for me): when to use case/if versus function heads? Roughly, I've been using cases to reformat the returns of a function call, but the decision trips me up every time. > > Judson > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Tue Mar 3 14:45:20 2015 From: g@REDACTED (Garrett Smith) Date: Tue, 3 Mar 2015 14:45:20 +0100 Subject: [erlang-questions] Design patterns? In-Reply-To: References: Message-ID: A quick thought on the case vs function question... I personally tend to eventually replace case expressions shortly after writing them as at that point it becomes clearer to me "what's going on" there. If a well named function can clarify what's gong on, I'll use it. Otherwise I leave the case expression alone. I end up with very few case expressions. I think the example you give - translating the shape of some result - is arguably a good one for sticking with case... As a function can start to take more effort to understand at a glance than the case. I'd stick with the rule "make it obvious what's going on" and use your best judgment along the way. If you're working with a team, see what people like over time and converge on that. On Mar 2, 2015 8:21 PM, "Judson Lester" wrote: > As I'm becoming more comfortable and proficient in Erlang, I'm finding > there there are interesting patterns that begin to emerge that I'm not sure > I've seen elsewhere. I'm wondering if there's a collection somewhere, maybe > c2 style? > > One example is a complicated data processing: I've started creating a > special purpose record and dispatching based on its fields. That includes > short-circuiting on errors, constructing syntheses from simpler data, etc. > Since I've stumbled onto it, I've been really liking how it can bring the > full force of pattern matching to complex processing. I do worry that it's > a bit of a smell though. If the processing can be simplified, that might be > better, but it's better, imo, than a long ladder of > maybe_compute_other_thing style functions. > > And an open question (for me): when to use case/if versus function heads? > Roughly, I've been using cases to reformat the returns of a function call, > but the decision trips me up every time. > > Judson > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.youngkin@REDACTED Tue Mar 3 15:36:06 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Tue, 3 Mar 2015 07:36:06 -0700 Subject: [erlang-questions] Why isn't 'EXIT' message being received/processed? In-Reply-To: References: Message-ID: Hi Robert, Thanks for confirming that I did indeed understand what was going on. The code ends up calling a gen_server, albeit indirectly. I'm using the RabbitMQ amqp library, with a function call. The associated amqp module does the gen_server call. Thanks again for confirming. Cheers, Rich On Mon, Mar 2, 2015 at 8:02 AM, Robert Virding wrote: > Yes, your explanation is correct. When the signal is converted to a > message it behaves just like any other message and is added to the end of > the queue. > > How are you sending to the child process? If you just do Pid ! Msg then > there will be no error if the process has died. > > Robert > > > On 26 February 2015 at 01:36, Youngkin, Rich > wrote: > >> I have an explanation for why it appears as if an 'EXIT' message isn't >> received and processed. It seems kind of obvious looking back, but also >> subtle enough that I don't feel like a complete idiot :) Hopefully this >> may help someone else who trips over the problem. I'm also interested in >> feedback, especially concerning some alternatives I describe below for >> addressing it. >> >> So to recap, I have a process that creates a process using spawn_link. >> This parent process has a receive loop with a clause that matches 'EXIT'. >> The problem I encountered was that the child's 'EXIT' messages weren't >> always being received by the parent process before the parent process tried >> to send a message to the linked child process. In this case the parent >> process would fail with a "noproc" error (i.e., the child process no longer >> exists). >> >> The cause appears to be the order of messages received in the parent's >> mailbox. The 'EXIT' message is handled just like any other message in that >> a process's mailbox behaves like a queue (FIFO). So the 'EXIT' message is >> placed in the mailbox after any other unprocessed messages. Those messages >> will be handled before the 'EXIT' message. In my case, one of the prior >> messages results in sending a message (PID ! Message) to the failed child >> process before the 'EXIT' message is seen, a simple race condition. I have >> seen test results that support this theory. Am I correctly characterizing >> the handling of 'EXIT' messages WRT general mailbox behavior? >> >> Since this behavior is non-deterministic my simple approach of handling >> 'EXIT' messages won't work. Alternatives I'm considering include: >> 1. Selective receives, but I don't really see this as a robust approach >> to handling this given the description of this approach in LYSE. LYSE also >> describes a better approach using min_heap, but this seems like overkill in >> my case. >> 2. Handling 'EXIT' messages and backing that up with a try/catch for the >> race condition. >> 3. Forget linking altogether and just handle the problem with a try/catch >> block >> >> I'm leaning towards option 3 and I'm interested in other opinions/options. >> >> Finally, this seems like a fairly common use case, especially in RabbitMQ >> applications (where the recommendation is to monitor/link amqp_channel >> processes). But maybe I'm missing something, or misusing 'EXIT'? Any >> comments? >> >> Thanks, >> Rich >> >> On Tue, Feb 17, 2015 at 3:25 PM, Youngkin, Rich < >> richard.youngkin@REDACTED> wrote: >> >>> Hi, >>> >>> I've got an app that spawn_links processes with trap_exit. I'm killing >>> the linked processes but the monitoring process isn't always receiving the >>> 'EXIT' message. Here are some code snippets: >>> >>> ... >>> process_flag(trap_exit, true), >>> link(Connection), >>> link(Channel), >>> ... >>> >>> loop(State) -> >>> ... >>> {'EXIT', What, Reason} -> >>> do_something_smart(); >>> >>> ... >>> >>> Connection and Channel are a RabbitMQ connection and channel (although >>> that's not necessarily important to know). I'm manually running "force >>> close" on the connection via the RabbitMQ admin interface to trigger the >>> 'EXIT'. In one case the 'EXIT' message is received and in the other case >>> it isn't. Here are more code snippets to illustrate this (same loop/1 >>> function as above): >>> >>> loop(#state{channel=Channel, delay_ack= DelayAck} = State) -> >>> ... >>> >>> {#'basic.deliver'{delivery_tag=DeliveryTag}, Content} -> >>> ... do something with the content >>> case DelayAck of >>> true -> >>> timer:sleep(500), %% allow time for 'EXIT' to arrive in the >>> mailbox before "ack_delivery" message >>> self() ! {ack_delivery, Channel, DeliveryTag}, >>> loop(State); >>> _ -> >>> amqp_channel:call(Channel, >>> #'basic.ack'{delivery_tag=DeliveryTag}), >>> loop(State) >>> end; >>> >>> {ack_delivery, Channel, DeliveryTag} -> >>> timer:sleep(50), %% ack delay >>> amqp_channel:call(Channel, #'basic.ack'{delivery_tag=DeliveryTag}), >>> loop(State); >>> >>> ... >>> >>> In the above snippet DelayAck specifies whether the actual ack happens >>> immediately or as a result of sending another message through loop/1. >>> When DelayAck is false the 'EXIT' message is received as expected. When >>> DelayAck is true there is a sleep of 500ms in order to allow the 'EXIT' to >>> arrive in the mailbox before the {ack_delivery, Channel, DeliveryTag} >>> message. But in this case the 'EXIT' message isn't received. The process >>> instead fails with a "noproc" when invoking amqp_channel:call/2 in >>> {ack_delivery...}. This makes sense since the Channel is now invalid, but I >>> did expect 'EXIT' to be received first thereby avoiding this failure. >>> Increasing the sleep before sending the {ack_delivery...} message doesn't >>> make any difference (except to delay the "noproc" failure). The behavior >>> described in this paragraph is consistent across several test runs. >>> >>> What would explain why the 'EXIT' message isn't received (ahead of the >>> ack_delivery message, or even at all) in the DelayAck case? >>> >>> Thanks, >>> Rich >>> >>> >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik_pawlak@REDACTED Tue Mar 3 17:08:08 2015 From: dominik_pawlak@REDACTED (Dominik Pawlak) Date: Tue, 03 Mar 2015 17:08:08 +0100 Subject: [erlang-questions] SNMP Development Toolkit In-Reply-To: References: Message-ID: <54F5DC68.4000603@yahoo.co.uk> I'm looking at snmp code from OTP 17.1 and the example indeed looks broken. The start function you are using takes Address as a parameter but then uses that value as TargetName and not as the ip of the device. You can use the longer alternative, which works for me (mib path may be different on your machine): snmp_ex2_simple_standard_test:start(["/opt/erlang6.1/lib/erlang/lib/snmp-4.25.1/priv/mibs/STANDARD-MIB"], "Agent Name", [{engine_id,""},{address,{192,168,1,1}},{community,"public"}]). On 03.03.2015 00:00, Frederic Bonfanti wrote: > Hi, > > I have been playing around with snmp but this giving me a hard time... > > here is the error I get: > > > snmp_ex2_simple_standard_test:start({192,168,1,1}). > snmpm:snmpm:mk_target_name(snmpUDPDomain, {{192,168,1,1},161}, > [{community, "public"}]) -> "192.168.1.1:161-v1". > > Command 1 (get-next [1,1]): error > {command_failed,not_found} > ... > > > SNMP works fine from both Mac OS X / snmpget and remote agent > perspectives... Only erlang SNMP toolkit refuses to operate properly. > > Any hint appreciated > > +F > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryankbrown@REDACTED Tue Mar 3 18:33:54 2015 From: ryankbrown@REDACTED (Ryan Brown) Date: Tue, 3 Mar 2015 10:33:54 -0700 Subject: [erlang-questions] Issues with clustering Mnesia running on different erlang versions? Message-ID: Hello, I am in the process of preparing a deployment of my erlang application that will include an upgrade from R15B01 to R16B. Currently all of our nodes are sharing clustered mnesia for the very little state information we keep. As part of our deployment process we need to take servers out of rotation, upgrade them, then start them and put them back in. Rolling through the cluster. This has never been an issue in the past. However, there is some concern in the group that there may be some issues this time as we are upgrading versions of erlang. Looking at the release notes, nothing stands-out to me. However, I thought I would reach-out to the community to see what experiences others have had with this and also see if there are any established best practices. Any feedback is greatly appreciated. Best, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyarly@REDACTED Tue Mar 3 18:44:47 2015 From: nyarly@REDACTED (Judson Lester) Date: Tue, 03 Mar 2015 17:44:47 +0000 Subject: [erlang-questions] Design patterns? References: <54f5712a.d295b40a.2a9a.6551@mx.google.com> Message-ID: On Tue, Mar 3, 2015 at 12:30 AM Gordon Guthrie wrote: > Generally function heads are 'better' than cases, particularly if there > are a lot of them... > > This email would be easier to answer if there was some code so people > could outline options... > I deliberately didn't include any code because I was more interested in talking about the overall idea ("do erlangers discuss design patterns?") than "it'd be better if you..." As is it seems like including examples without code was too much of a distraction :) I think I was coming to the (general?) conclusion about case statements: they're an intermediary step that are only occasionally left as-is. I think I'm also slowly understanding how powerful (and therefore important) the tooling is in Erlang - I'd figured out common_test on my own, and been integrating that with eunit slowly. But dialyzer is an amazing tool, and it seems like I should sink the time into learning xref, too. Together, they seem to influence the design and structure of Erlang in many little ways. The question remains though: do erlangers discuss design patterns? (I see a lot of "I'd do it this way..." which seems like sort of the same thing.) Judson -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Tue Mar 3 21:05:36 2015 From: radek@REDACTED (Rad Gruchalski) Date: Tue, 3 Mar 2015 21:05:36 +0100 Subject: [erlang-questions] {tls_alert,"handshake failure"} In-Reply-To: References: Message-ID: Alex, I believe, this is because you are using self signed certificates and the signing certificate provided in the bundle is not added to trusted certificates. Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Monday, 2 March 2015 at 21:46, Alex Hudich wrote: > Hi > > I?ve got some strange errors when I try to make SSL connection to a web-site with peer verification on. > > Here?s an example: > > I?ve downloaded PEM certificates from https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt > > Then I start erl and run a command ssl:start(). > > Then I try to connect somewhere (I renamed ca-bundle.crt file to a cacert.pem): > > 2> ssl:connect( "t.ileads.ru (http://t.ileads.ru)", 443, [{verify,verify_peer},{cacertfile,"cacert.pem"}]). > > =ERROR REPORT==== 2-Mar-2015::23:32:15 === > SSL: certify: ssl_handshake.erl:1403:Fatal error: handshake failure > {error,{tls_alert,"handshake failure"}} > > > Without peer verification everything went ok. > > What?s wrong? Or maybe I do something wrong? > > -- > cul8er, Alex. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Tue Mar 3 21:30:15 2015 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 3 Mar 2015 20:30:15 +0000 Subject: [erlang-questions] Cover compilation vs. dialyzer Message-ID: I've got a couple of modules in my project which exist purely to hold binary objects. That is: given a file foo.bin, I generate a module foo_bin, with a function bin/0 which has the original file inlined in it. Something like this: embed_file_in_beam(InputPath) -> {ok, Bytes} = file:read_file(InputPath), ModuleName = get_module_name(filename:basename(InputPath)), OutputPath = filename:join("ebin", ModuleName ++ ".beam"), % We'll export a function Mod:bin/0. Mod = list_to_atom(ModuleName), Fun = 'bin', % An Erlang module is a list of forms; we need three: Forms = [ module_form(Mod), % -module(foo). export_form(Fun), % -export([bin/0]). function_form(Fun, Bytes) % bin() -> <<...>>. ], {ok, Mod, Bin} = compile:forms(Forms, [debug_info]), ok = file:write_file(OutputPath, Bin). function_form(Fun, Binary) -> % a function, {function, 1, Fun, 0, % with one clause, [{clause, 1, [], [], % which has one expression, a binary, [{bin, 1, [ % made up of the stuff we first thought of. {bin_element, 1, {integer, 1, Byte}, default, default} || <> <= Binary ]} ]} ]}. However, cover compilation and dialyzer are fighting each-other over whether these files should include debug information or not. If I _don't_ include the debug_info option, then dialyzer fails complaining that there's no abstract code. If I _do_ include the debug_info option, then cover compilation fails, apparently while trying to find the original source file. Which doesn't exist. How can I keep both tools happy? Or, alternatively, is there a better way to embed binary resources in an Erlang module? And by "better", I don't mean "stick 'em in the priv directory". From roberto@REDACTED Tue Mar 3 21:32:30 2015 From: roberto@REDACTED (Roberto Ostinelli) Date: Tue, 3 Mar 2015 21:32:30 +0100 Subject: [erlang-questions] Yet Another MNESIA net split recover question Message-ID: Dear List, I have ram-only connected mnesia nodes. Every node inserts data of sockets that are connected to that specific node. I'm considering net splits events and the resulting partition event that happens with mnesia. When one of these happen, I can identify the data that relates to the other partitioned nodes, so on every node I remove all data of other nodes. After this operation, there cannot be any possible merge conflicts. The question is: how do I set mnesia to go back into syncing the nodes? I've seen that a common practice is to stop and restart mnesia after selecting a master node. This is not what I want: I have already successfully resolved all conflicts. I've seen in Ulf's unsplit that the function mnesia_controller:connect_nodes/2 is used to reconnect nodes. However, I cannot find any documentation for this function and I wander if that would be a good option. Any idea on how to reconnect nodes and have mnesia act "normal" again after a partitioned event without stopping/starting it? Best, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harit.subscriptions@REDACTED Tue Mar 3 22:32:28 2015 From: harit.subscriptions@REDACTED (Harit Himanshu) Date: Tue, 3 Mar 2015 13:32:28 -0800 Subject: [erlang-questions] How to calculate series expansion e^x In-Reply-To: References: <2E28711F-E72D-4E90-A708-CB2782B958FF@cs.otago.ac.nz> Message-ID: Richard and Alex Thanks a lot for your help. I got help up with my day job and could not try it out. Thanks a lot for your help on this problem. I tried a different version and it looks like following. Let me know if you see any issues with that -module(solution). -export([main/0]). main() -> {ok, [N]} = io:fread("", "~d"), Data = read_input([], N), [io:format("~p~n", [e_x(X)]) || X <- Data]. read_input(Input, N) -> case N of 0 -> lists:reverse(Input); _ -> {ok, [Num]} = io:fread("", "~s"), {NumFloat, _} = string:to_float(Num), read_input([NumFloat | Input], N - 1) end. e_x(X) -> 1 + lists:sum([math:pow(X, N) / fact(N) || N <- lists:seq(1, 9)]). fact(N) -> case N of 0 -> 1; 1 -> 1; _ -> N * fact(N - 1) end. On Wed, Feb 25, 2015 at 4:38 PM, Alex Alvarez wrote: > Or just simply... > > > -module(e_fun). > > -export ([start/2]). > > start (N, X) -> > 1 + step (N - 1, 1, X, 1.0, 0). > > step (0, _, _, _, S) -> S; > step (N, NN, X, Z, S) -> > ZZ = Z * X/NN, > step (N - 1, NN + 1, X, ZZ, S + ZZ). > > > Here I'm just reusing the each previous term (ZZ) of the Taylor series to > compute the next term and then add it up to the sum (S). > > Cheers, > Alex > > > > On 02/24/2015 10:27 PM, Richard A. O'Keefe wrote: > > On 25/02/2015, at 11:00 am, Harit Himanshu wrote: > > > I am trying to learn Functional Programming and Erlang by practicing problems available online. > > One question where I don't know about solving it is > > The series expansion of ex is given by: > > 1 + x + x2/2! + x3/3! + x4/4! + ....... > > Evaluate e^x for given values of x, by using the above expansion for the first 10 terms. > > > The problem statement could be found here > > Can someone guide me how this could be achieved in Erlang? > > The first 10 terms of exp(X) are > X X^2 X^3 X^9 > 1 + --- + --- + --- + ... + --- > 1 2 6 9! > This is a polynomial. We can evaluate it cheaply using > Horner's Rule. Any time you have a polynomial to > evaluate, you should think about using Horner's Rule. > > X / X / X / X \ \ \ > 1 + --- * | 1 + --- * | 1 + --- * ... | 1 + --- | ...| | > 1 \ 2 \ 3 \ 9 / / / > > We can see a building block here: 1 + (X/n)*Rest. > > So let's make a function for the building block: > > step(X, N, Rest) > when is_float(X), is_float(N), is_float(Rest) -> > 1.0 + (X/N)*Rest. > > There are 9 steps, which is small enough to do by hand: > (NINE steps to get TEN terms. I hope that's clear.) > > exp(X) > when is_float(X) -> > step(X, 1.0, step(X, 2.0, step(X, 3.0, > step(X, 4.0, step(X, 5.0, step(X, 6.0, > step(X, 7.0, step(X, 8.0, step(X, 9.0, 1.0))))))))). > > > I should point out that this is a lousy way to compute > exp(X) for abs(X) "large". Waving hands vaguely, you > want X^10/10! "small". The relative error for X = 1.0 > is -1.1e-7, for X = 2.0 is -4.6e-5, and for X = 4.0 is > a scary -0.0081. > > One technique that's used in cases like this is > RANGE REDUCTION. e^x = 2^(1.442695... * x). > To begin, scale x by log of e to the base 2, > and separate that into an integer part N and a fraction > part F. e^x is then 2^(N+F) = 2^N*2^F. Since F is > "small", we can use something like this polynomial. > And then we can use the equivalent of C's ldexp() to > handle the 2^N* part. Or we could if Erlang _had_ an > equivalent of ldexp(). > > You don't really need the is_float/1 tests; I put them in > so that the compiler could generate better native code. > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://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 bchesneau@REDACTED Tue Mar 3 23:23:06 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 3 Mar 2015 23:23:06 +0100 Subject: [erlang-questions] unexpected message {error, closed} on passive SSL socket Message-ID: Hi all, When closing a passive SSL socket ({active, false}) I get an unexpected message `{error, closed}` in the process on Erlang 17.4 is this a known issue? The SSL socket is connected with the following SSL options: [{verify, verify_none}, {reuse_sessions, true}]; And the other inets options: [binary, {active, false}, {packet, raw}], Any idea? - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido.rumi@REDACTED Wed Mar 4 00:32:05 2015 From: guido.rumi@REDACTED (Guido Rumi) Date: Tue, 3 Mar 2015 20:32:05 -0300 Subject: [erlang-questions] How to calculate series expansion e^x In-Reply-To: References: <2E28711F-E72D-4E90-A708-CB2782B958FF@cs.otago.ac.nz> Message-ID: I would change fact(N) -> case N of 0 -> 1; 1 -> 1; _ -> N * fact(N - 1) end. to fact(N) -> fact_tr(N, 1). fact_tr(N, Acc) -> case N of 0 -> Acc; 1 -> Acc; _ -> fact_tr (N - 1, N * Acc) end. To make it more efficient http://stackoverflow.com/questions/33923/what-is-tail-recursion On Tue, Mar 3, 2015 at 6:32 PM, Harit Himanshu < harit.subscriptions@REDACTED> wrote: > Richard and Alex > > Thanks a lot for your help. I got help up with my day job and could not > try it out. Thanks a lot for your help on this problem. > I tried a different version and it looks like following. Let me know if > you see any issues with that > > -module(solution). > -export([main/0]). > > main() -> > {ok, [N]} = io:fread("", "~d"), > Data = read_input([], N), > [io:format("~p~n", [e_x(X)]) || X <- Data]. > > read_input(Input, N) -> > case N of > 0 -> lists:reverse(Input); > _ -> {ok, [Num]} = io:fread("", "~s"), > {NumFloat, _} = string:to_float(Num), > read_input([NumFloat | Input], N - 1) > end. > > e_x(X) -> > 1 + lists:sum([math:pow(X, N) / fact(N) || N <- lists:seq(1, 9)]). > > fact(N) -> > case N of > 0 -> 1; > 1 -> 1; > _ -> N * fact(N - 1) > end. > > On Wed, Feb 25, 2015 at 4:38 PM, Alex Alvarez wrote: > >> Or just simply... >> >> >> -module(e_fun). >> >> -export ([start/2]). >> >> start (N, X) -> >> 1 + step (N - 1, 1, X, 1.0, 0). >> >> step (0, _, _, _, S) -> S; >> step (N, NN, X, Z, S) -> >> ZZ = Z * X/NN, >> step (N - 1, NN + 1, X, ZZ, S + ZZ). >> >> >> Here I'm just reusing the each previous term (ZZ) of the Taylor series to >> compute the next term and then add it up to the sum (S). >> >> Cheers, >> Alex >> >> >> >> On 02/24/2015 10:27 PM, Richard A. O'Keefe wrote: >> >> On 25/02/2015, at 11:00 am, Harit Himanshu wrote: >> >> >> I am trying to learn Functional Programming and Erlang by practicing problems available online. >> >> One question where I don't know about solving it is >> >> The series expansion of ex is given by: >> >> 1 + x + x2/2! + x3/3! + x4/4! + ....... >> >> Evaluate e^x for given values of x, by using the above expansion for the first 10 terms. >> >> >> The problem statement could be found here >> >> Can someone guide me how this could be achieved in Erlang? >> >> The first 10 terms of exp(X) are >> X X^2 X^3 X^9 >> 1 + --- + --- + --- + ... + --- >> 1 2 6 9! >> This is a polynomial. We can evaluate it cheaply using >> Horner's Rule. Any time you have a polynomial to >> evaluate, you should think about using Horner's Rule. >> >> X / X / X / X \ \ \ >> 1 + --- * | 1 + --- * | 1 + --- * ... | 1 + --- | ...| | >> 1 \ 2 \ 3 \ 9 / / / >> >> We can see a building block here: 1 + (X/n)*Rest. >> >> So let's make a function for the building block: >> >> step(X, N, Rest) >> when is_float(X), is_float(N), is_float(Rest) -> >> 1.0 + (X/N)*Rest. >> >> There are 9 steps, which is small enough to do by hand: >> (NINE steps to get TEN terms. I hope that's clear.) >> >> exp(X) >> when is_float(X) -> >> step(X, 1.0, step(X, 2.0, step(X, 3.0, >> step(X, 4.0, step(X, 5.0, step(X, 6.0, >> step(X, 7.0, step(X, 8.0, step(X, 9.0, 1.0))))))))). >> >> >> I should point out that this is a lousy way to compute >> exp(X) for abs(X) "large". Waving hands vaguely, you >> want X^10/10! "small". The relative error for X = 1.0 >> is -1.1e-7, for X = 2.0 is -4.6e-5, and for X = 4.0 is >> a scary -0.0081. >> >> One technique that's used in cases like this is >> RANGE REDUCTION. e^x = 2^(1.442695... * x). >> To begin, scale x by log of e to the base 2, >> and separate that into an integer part N and a fraction >> part F. e^x is then 2^(N+F) = 2^N*2^F. Since F is >> "small", we can use something like this polynomial. >> And then we can use the equivalent of C's ldexp() to >> handle the 2^N* part. Or we could if Erlang _had_ an >> equivalent of ldexp(). >> >> You don't really need the is_float/1 tests; I put them in >> so that the compiler could generate better native code. >> >> _______________________________________________ >> erlang-questions mailing listerlang-questions@REDACTED://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 harit.subscriptions@REDACTED Wed Mar 4 00:42:00 2015 From: harit.subscriptions@REDACTED (Harit Himanshu) Date: Tue, 3 Mar 2015 15:42:00 -0800 Subject: [erlang-questions] How to calculate series expansion e^x In-Reply-To: References: <2E28711F-E72D-4E90-A708-CB2782B958FF@cs.otago.ac.nz> Message-ID: Thanks Guido, That is more useful. On Tue, Mar 3, 2015 at 3:32 PM, Guido Rumi wrote: > I would change > > fact(N) -> > case N of > 0 -> 1; > 1 -> 1; > _ -> N * fact(N - 1) > end. > > to > > fact(N) -> > fact_tr(N, 1). > > fact_tr(N, Acc) -> > case N of > 0 -> Acc; > 1 -> Acc; > _ -> fact_tr (N - 1, N * Acc) > end. > > To make it more efficient > http://stackoverflow.com/questions/33923/what-is-tail-recursion > > On Tue, Mar 3, 2015 at 6:32 PM, Harit Himanshu < > harit.subscriptions@REDACTED> wrote: > >> Richard and Alex >> >> Thanks a lot for your help. I got help up with my day job and could not >> try it out. Thanks a lot for your help on this problem. >> I tried a different version and it looks like following. Let me know if >> you see any issues with that >> >> -module(solution). >> -export([main/0]). >> >> main() -> >> {ok, [N]} = io:fread("", "~d"), >> Data = read_input([], N), >> [io:format("~p~n", [e_x(X)]) || X <- Data]. >> >> read_input(Input, N) -> >> case N of >> 0 -> lists:reverse(Input); >> _ -> {ok, [Num]} = io:fread("", "~s"), >> {NumFloat, _} = string:to_float(Num), >> read_input([NumFloat | Input], N - 1) >> end. >> >> e_x(X) -> >> 1 + lists:sum([math:pow(X, N) / fact(N) || N <- lists:seq(1, 9)]). >> >> fact(N) -> >> case N of >> 0 -> 1; >> 1 -> 1; >> _ -> N * fact(N - 1) >> end. >> >> On Wed, Feb 25, 2015 at 4:38 PM, Alex Alvarez wrote: >> >>> Or just simply... >>> >>> >>> -module(e_fun). >>> >>> -export ([start/2]). >>> >>> start (N, X) -> >>> 1 + step (N - 1, 1, X, 1.0, 0). >>> >>> step (0, _, _, _, S) -> S; >>> step (N, NN, X, Z, S) -> >>> ZZ = Z * X/NN, >>> step (N - 1, NN + 1, X, ZZ, S + ZZ). >>> >>> >>> Here I'm just reusing the each previous term (ZZ) of the Taylor series >>> to compute the next term and then add it up to the sum (S). >>> >>> Cheers, >>> Alex >>> >>> >>> >>> On 02/24/2015 10:27 PM, Richard A. O'Keefe wrote: >>> >>> On 25/02/2015, at 11:00 am, Harit Himanshu wrote: >>> >>> >>> I am trying to learn Functional Programming and Erlang by practicing problems available online. >>> >>> One question where I don't know about solving it is >>> >>> The series expansion of ex is given by: >>> >>> 1 + x + x2/2! + x3/3! + x4/4! + ....... >>> >>> Evaluate e^x for given values of x, by using the above expansion for the first 10 terms. >>> >>> >>> The problem statement could be found here >>> >>> Can someone guide me how this could be achieved in Erlang? >>> >>> The first 10 terms of exp(X) are >>> X X^2 X^3 X^9 >>> 1 + --- + --- + --- + ... + --- >>> 1 2 6 9! >>> This is a polynomial. We can evaluate it cheaply using >>> Horner's Rule. Any time you have a polynomial to >>> evaluate, you should think about using Horner's Rule. >>> >>> X / X / X / X \ \ \ >>> 1 + --- * | 1 + --- * | 1 + --- * ... | 1 + --- | ...| | >>> 1 \ 2 \ 3 \ 9 / / / >>> >>> We can see a building block here: 1 + (X/n)*Rest. >>> >>> So let's make a function for the building block: >>> >>> step(X, N, Rest) >>> when is_float(X), is_float(N), is_float(Rest) -> >>> 1.0 + (X/N)*Rest. >>> >>> There are 9 steps, which is small enough to do by hand: >>> (NINE steps to get TEN terms. I hope that's clear.) >>> >>> exp(X) >>> when is_float(X) -> >>> step(X, 1.0, step(X, 2.0, step(X, 3.0, >>> step(X, 4.0, step(X, 5.0, step(X, 6.0, >>> step(X, 7.0, step(X, 8.0, step(X, 9.0, 1.0))))))))). >>> >>> >>> I should point out that this is a lousy way to compute >>> exp(X) for abs(X) "large". Waving hands vaguely, you >>> want X^10/10! "small". The relative error for X = 1.0 >>> is -1.1e-7, for X = 2.0 is -4.6e-5, and for X = 4.0 is >>> a scary -0.0081. >>> >>> One technique that's used in cases like this is >>> RANGE REDUCTION. e^x = 2^(1.442695... * x). >>> To begin, scale x by log of e to the base 2, >>> and separate that into an integer part N and a fraction >>> part F. e^x is then 2^(N+F) = 2^N*2^F. Since F is >>> "small", we can use something like this polynomial. >>> And then we can use the equivalent of C's ldexp() to >>> handle the 2^N* part. Or we could if Erlang _had_ an >>> equivalent of ldexp(). >>> >>> You don't really need the is_float/1 tests; I put them in >>> so that the compiler could generate better native code. >>> >>> _______________________________________________ >>> erlang-questions mailing listerlang-questions@REDACTED://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 gumm@REDACTED Wed Mar 4 00:42:01 2015 From: gumm@REDACTED (Jesse Gumm) Date: Tue, 3 Mar 2015 17:42:01 -0600 Subject: [erlang-questions] New Erlang EBook In-Reply-To: <54F595FA.9060006@gmail.com> References: <54F595FA.9060006@gmail.com> Message-ID: Awesome! Thanks for sharing, Zach, I'll definitely be checking this out. -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm On Mar 3, 2015 5:07 AM, "Zachary Kessin" wrote: > Hi everyone, > > I have just put out a new Ebook on Using QuickCheck on Erlang. It covers > all three major erlang QuickCheck versions (Quviq, PropEr, and Triq). and > will take you from your first property to being a QuickCheck master. > > Right now it is in Early Release. The content is being developed and it > should be finished by Erlang Factory SF. > > If you buy it today you will get all the updates as I work on it > > http://www.erlang-quickcheck-book.com/ > -- > Zachary Kessin > Mostly Erlang Podcast > Skype: zachkessin > Twitter: @zkessin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Wed Mar 4 00:59:00 2015 From: zxq9@REDACTED (zxq9) Date: Wed, 04 Mar 2015 08:59 +0900 Subject: [erlang-questions] How to calculate series expansion e^x In-Reply-To: References: Message-ID: <7834163.fiYbEUv3ce@changa> Mostly a point of style, perhaps, but I think matching in the function head in this case is a bit more readable (it may also wind up being more efficient). This is more what I would expect to see in an Erlang program: fact(N) -> fact(N, 1). fact(0, Acc) -> Acc; fact(1, Acc) -> Acc; fact(N, Acc) -> fact(N - 1, N * Acc). On 2015?3?3? ??? 20:32:05 Guido Rumi wrote: > I would change > > fact(N) -> > case N of > 0 -> 1; > 1 -> 1; > _ -> N * fact(N - 1) > end. > > to > > fact(N) -> > fact_tr(N, 1). > > fact_tr(N, Acc) -> > case N of > 0 -> Acc; > 1 -> Acc; > _ -> fact_tr (N - 1, N * Acc) > end. > > To make it more efficient > http://stackoverflow.com/questions/33923/what-is-tail-recursion > > On Tue, Mar 3, 2015 at 6:32 PM, Harit Himanshu < > > harit.subscriptions@REDACTED> wrote: > > Richard and Alex > > > > Thanks a lot for your help. I got help up with my day job and could not > > try it out. Thanks a lot for your help on this problem. > > I tried a different version and it looks like following. Let me know if > > you see any issues with that > > > > -module(solution). > > -export([main/0]). > > > > main() -> > > > > {ok, [N]} = io:fread("", "~d"), > > Data = read_input([], N), > > [io:format("~p~n", [e_x(X)]) || X <- Data]. > > > > read_input(Input, N) -> > > > > case N of > > > > 0 -> lists:reverse(Input); > > _ -> {ok, [Num]} = io:fread("", "~s"), > > > > {NumFloat, _} = string:to_float(Num), > > read_input([NumFloat | Input], N - 1) > > > > end. > > > > e_x(X) -> > > > > 1 + lists:sum([math:pow(X, N) / fact(N) || N <- lists:seq(1, 9)]). > > > > fact(N) -> > > > > case N of > > > > 0 -> 1; > > 1 -> 1; > > _ -> N * fact(N - 1) > > > > end. > > > > On Wed, Feb 25, 2015 at 4:38 PM, Alex Alvarez wrote: > >> Or just simply... > >> > >> -module(e_fun). > >> > >> -export ([start/2]). > >> > >> start (N, X) -> > >> > >> 1 + step (N - 1, 1, X, 1.0, 0). > >> > >> step (0, _, _, _, S) -> S; > >> step (N, NN, X, Z, S) -> > >> > >> ZZ = Z * X/NN, > >> > >> step (N - 1, NN + 1, X, ZZ, S + ZZ). > >> > >> Here I'm just reusing the each previous term (ZZ) of the Taylor series to > >> compute the next term and then add it up to the sum (S). > >> > >> Cheers, > >> Alex > >> > >> > >> > >> On 02/24/2015 10:27 PM, Richard A. O'Keefe wrote: > >> > >> On 25/02/2015, at 11:00 am, Harit Himanshu wrote: > >> I am trying to learn Functional Programming and Erlang by practicing > >> problems available online.>> > >> One question where I don't know about solving it is > >> > >> The series expansion of ex is given by: > >> > >> 1 + x + x2/2! + x3/3! + x4/4! + ....... > >> > >> Evaluate e^x for given values of x, by using the above expansion for the > >> first 10 terms. > >> > >> > >> The problem statement could be found here > >> > >> Can someone guide me how this could be achieved in Erlang? > >> > >> The first 10 terms of exp(X) are > >> > >> X X^2 X^3 X^9 > >> > >> 1 + --- + --- + --- + ... + --- > >> > >> 1 2 6 9! > >> > >> This is a polynomial. We can evaluate it cheaply using > >> Horner's Rule. Any time you have a polynomial to > >> evaluate, you should think about using Horner's Rule. > >> > >> X / X / X / X \ \ \ > >> > >> 1 + --- * | 1 + --- * | 1 + --- * ... | 1 + --- | ...| | > >> > >> 1 \ 2 \ 3 \ 9 / / / > >> > >> We can see a building block here: 1 + (X/n)*Rest. > >> > >> So let's make a function for the building block: > >> > >> step(X, N, Rest) > >> > >> when is_float(X), is_float(N), is_float(Rest) -> > >> > >> 1.0 + (X/N)*Rest. > >> > >> There are 9 steps, which is small enough to do by hand: > >> (NINE steps to get TEN terms. I hope that's clear.) > >> > >> exp(X) > >> > >> when is_float(X) -> > >> > >> step(X, 1.0, step(X, 2.0, step(X, 3.0, > >> step(X, 4.0, step(X, 5.0, step(X, 6.0, > >> step(X, 7.0, step(X, 8.0, step(X, 9.0, 1.0))))))))). > >> > >> I should point out that this is a lousy way to compute > >> exp(X) for abs(X) "large". Waving hands vaguely, you > >> want X^10/10! "small". The relative error for X = 1.0 > >> is -1.1e-7, for X = 2.0 is -4.6e-5, and for X = 4.0 is > >> a scary -0.0081. > >> > >> One technique that's used in cases like this is > >> RANGE REDUCTION. e^x = 2^(1.442695... * x). > >> To begin, scale x by log of e to the base 2, > >> and separate that into an integer part N and a fraction > >> part F. e^x is then 2^(N+F) = 2^N*2^F. Since F is > >> "small", we can use something like this polynomial. > >> And then we can use the equivalent of C's ldexp() to > >> handle the 2^N* part. Or we could if Erlang _had_ an > >> equivalent of ldexp(). > >> > >> You don't really need the is_float/1 tests; I put them in > >> so that the compiler could generate better native code. > >> > >> _______________________________________________ > >> erlang-questions mailing > >> listerlang-questions@REDACTED://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 ok@REDACTED Wed Mar 4 02:02:34 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 4 Mar 2015 14:02:34 +1300 Subject: [erlang-questions] Design patterns? In-Reply-To: References: <54f5712a.d295b40a.2a9a.6551@mx.google.com> Message-ID: <158ED64F-D88C-496A-B73E-48BD12E138E6@cs.otago.ac.nz> On 4/03/2015, at 6:44 am, Judson Lester wrote: > On Tue, Mar 3, 2015 at 12:30 AM Gordon Guthrie wrote: > Generally function heads are 'better' than cases, particularly if there are a lot of them... > > This email would be easier to answer if there was some code so people could outline options... > > I deliberately didn't include any code because I was more interested in talking about the overall idea ("do erlangers discuss design patterns?") than "it'd be better if you..." Discussing "overall ideas" without examining concrete cases is like arguing about orchestration without looking at scores: futile. If we are going to pontificate about airy nothings, let me remind you of the MASTER RULE: The aim of programming is to COMMUNICATE. So do whatever is clearest in context. That's it. If we want to make any progress past that, we *have* to examine *real* code that someone seriously intends to use. And of course things depend on the current state of the language. What was the best style at one time may cease to be so when something better becomes available. Let's take "view patterns" from Haskell as an example. Let's look at the classic back-to-back list implementation of queues. data Queue t = Queue [t] [t] left_view :: Queue t -> Maybe (t, Queue t) left_view (Queue (e:es) bs) = Just (e, Queue es bs) left_view (Queue [] bs) = case reverse bs of (e:es) -> Just (e, Queue es []) [] -> Nothing Now suppose we want to fold over the elements of a queue. (Yes, I know this is not the best way to do it.) fold :: (a -> b -> a) -> a -> Queue b -> a fold f x q = case left_view q of Nothing -> x Just (e, q') -> fold f (f x e) q' Frankly, it would be silly to invent a new function just to replace the case expression here. That function would only be _useful_ as part of the definition of fold. Now view patterns are patterns of the form (function -> pattern), with the semantics that the function expression is evaluated and applied to whatever you are matching, and then the result is matched (or not) by the pattern. With that extension, you can write fold f x (left_view -> Nothing) = x fold f x (left_view -> Just (e, q)) = fold f (f x e) q While it looks as though the function will be evaluated twice, we expect the compiler to optimise that to a single call. The code we get from each version of fold should be pretty much the same. If Erlang had a class of functions known to the compiler to be pure, it could have view patterns too, and then the question about whether to use case or not would often have a different answer. By the way, the 'case' in left_view is also an example where I think it would be silly to introduce a new function. So there are two questions: * Does the language include view patterns (or abstract patterns)? * Does the case *make sense* as a separate function? > I think I was coming to the (general?) conclusion about case statements: they're an intermediary step that are only occasionally left as-is. Wrong answer. The right answer is the UNIVERSAL EXPERT ANSWER: It all depends. Sometimes 'case' will be good. Sometimes it won't. IT ALL DEPENDS. By examining REAL CONCRETE EXAMPLES we may be able to induce some guidelines. Without examining real concrete examples, we're chasing (and swallowing) wind and end up producing only wind. > The question remains though: do erlangers discuss design patterns? (I see a lot of "I'd do it this way..." which seems like sort of the same thing.) When the design patterns book came out, the reaction of many Lispers and Smalltalkers are "design patterns are what you talk about when your language makes everything look hard". Half fun and full earnest. Let's look at some examples. format_exception({Class,Term,Trace}) when is_atom(Class), is_list(Trace) -> case is_stacktrace(Trace) of true -> io_lib:format("~w:~P\n~s", [Class, Term, 15, format_stacktrace(Trace)]); false -> format_term(Term) end; format_exception(Term) -> format_term(Term). is_stacktrace/1 is a function that examines a list checking that every element is {atom,atom,integer} or {atom,atom,list}. If we had -pure([is_stacktrace/1]). and view patterns that relied on checked purity, this could be format_exception({Class = (is_atom->true), Term, Trace = (is_stacktrace->true)}) -> io_lib:format("~w:~P\n~s", [Class, Term, 15, format_stacktrace(Trace)]); format_exception(Term) -> format_term(Term). Or even if -pure functions were allowed in guards, this could be format_exception({Class,Term,Trace}) when is_atom(Class), is_stacktrace(Trace) -> io_lib:format("~w:~P\n~s", [Class, Term, 15, format_stacktrace(Trace)]); format_exception(Term) -> format_term(Term). The constraint for a pure function is that it may not contain send or receive and may only call pure BIFs and other pure functions. Ideally it should be obviously terminating. dlist_flatten(Xs) -> case dlist_next(Xs) of [X | Xs1] -> [X | dlist_flatten(Xs1)]; [] -> [] end. This is a textbook example of where a view pattern would be just right: dlist_flatten((dlist_step -> [X|Xs1])) -> [X | dlist_flatten(Xs1); dlist_flatten((dlist_step -> [])) -> []. except that there are much better ways to achieve the same end. fun_parent(F) -> {name, N} = erlang:fun_info(F, name), case erlang:fun_info(F, type) of {type, external} -> N; {type, local} -> S = atom_to_list(N), list_to_atom(string:sub_string(S, 2, string:chr(S, $/) - 1)) end. I'm quite unhappy about this function because it is strongly coupled to the precise form of the atom returned by fun_info(_, name) for local functions, and that is not documented in http://www.erlang.org/doc/man/erlang.html#fun_info-1 A comment explaining what the format is assumed to be is needed here. That would do a lot to improve the understandability of this code; splitting the 'case' out as a separate function would, if anything, worsen it. Now splitting out parent_from_local_name(N) -> list_to_atom(string:sub_string(S, 2, string:chr(S, $/) - 1)). *would* improve readability, especially given that vital comment. try_apply(F, Arg) -> case erlang:fun_info(F, arity) of {arity, 1} -> {module, M} = erlang:fun_info(F, module), {name, N} = erlang:fun_info(F, name), try_apply(F, Arg, M, N); _ -> {error, badarity} end. It's not clear to me why this wasn't try_apply(F, Arg) when is_function(F, 1) -> {module, M} = erlang:fun_info(F, module), {name, N} = erlang:fun_info(F, name), try_apply(F, Arg, M, N); try_apply(_, _) -> {error, badarity}. I have a rule of thumb. Pick ANY local property of code. Examine a non-trivial body of code, looking only at matches for that property. You WILL find things that could be improved. "Uses 'case'" is a property of this kind. So is "contains the letter Z". From ok@REDACTED Wed Mar 4 03:29:54 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 4 Mar 2015 15:29:54 +1300 Subject: [erlang-questions] How to calculate series expansion e^x In-Reply-To: References: <2E28711F-E72D-4E90-A708-CB2782B958FF@cs.otago.ac.nz> Message-ID: <752E6B77-B016-4E27-BAB6-A39764B0D317@cs.otago.ac.nz> On 4/03/2015, at 10:32 am, Harit Himanshu wrote: > > e_x(X) -> > 1 + lists:sum([math:pow(X, N) / fact(N) || N <- lists:seq(1, 9)]). If you want *clarity*, then you should not make 1 a special case. 1 is just math:pow(X, 0)/fact(0), so lists:sum([math:pow(X, N) / fact(N) || N <- lists:seq(0, 9)]). does the job more simply. BUT either way, this is inefficient and inaccurate. I explained Horner's rule. It is also uncommented. In my earlier reply I pointed out that this is sort of OK for small values of X but grossly inaccurate for values of X >= 1. There desperately needs to be a comment explaining this limitation. > > fact(N) -> > case N of > 0 -> 1; > 1 -> 1; > _ -> N * fact(N - 1) > end. This is problematic in several ways. First, if N < 0, it will loop forever instead of failing sensibly. Second, if N is a float but not integral, the factorial function is indeed defined, but _this_ function will loop forever. % fact(N) = N! for non-negative integer N. % This module only needs 0 <= N <= 9. fact(N) when is_integer(N), N >= 0 -> fact_loop(1, N, 1). fact_loop(A, B, R) when A < B -> fact_loop(A+1, B-1, (A*B)*R); fact_loop(A, A, R) -> A*R; fact_loop(_, _, R) -> R. (This is adapted from my Smalltalk system. It's not the _best_ way to implement factorial, but it's _better_ than the naive loop.) http://www.luschny.de/math/factorial/FastFactorialFunctions.htm is an interesting page on computing factorials. From gguthrie@REDACTED Wed Mar 4 09:11:50 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Wed, 4 Mar 2015 08:11:50 +0000 Subject: [erlang-questions] Design patterns? In-Reply-To: References: <54f5712a.d295b40a.2a9a.6551@mx.google.com> Message-ID: <0F62A367-4151-4815-9500-0C9F5B0DB2F4@basho.com> Judson The key thing here is the story of OTP. Erlang was deployed and a number of systems were built. These systems (and the patterns they used) were analysed and then the OTP libraries (and behaviours) which encapsulate the common patterns were released. So Erlanger?s don?t tend to talk about ?design patterns? so much as ?use OPT? It?s a bit IKEA-like - a design pattern sez ?this is how you build a wheel? - IKEA sez "all all furniture uses the same wheel - this is the wheel" Gordon > Le 3 mars 2015 ? 17:44, Judson Lester a ?crit : > > On Tue, Mar 3, 2015 at 12:30 AM Gordon Guthrie > wrote: > Generally function heads are 'better' than cases, particularly if there are a lot of them... > > This email would be easier to answer if there was some code so people could outline options... > > I deliberately didn't include any code because I was more interested in talking about the overall idea ("do erlangers discuss design patterns?") than "it'd be better if you..." As is it seems like including examples without code was too much of a distraction :) > > I think I was coming to the (general?) conclusion about case statements: they're an intermediary step that are only occasionally left as-is. > > I think I'm also slowly understanding how powerful (and therefore important) the tooling is in Erlang - I'd figured out common_test on my own, and been integrating that with eunit slowly. But dialyzer is an amazing tool, and it seems like I should sink the time into learning xref, too. Together, they seem to influence the design and structure of Erlang in many little ways. > > The question remains though: do erlangers discuss design patterns? (I see a lot of "I'd do it this way..." which seems like sort of the same thing.) > > Judson -------------- next part -------------- An HTML attachment was scrubbed... URL: From alttagil@REDACTED Wed Mar 4 09:34:54 2015 From: alttagil@REDACTED (Alex Hudich) Date: Wed, 4 Mar 2015 11:34:54 +0300 Subject: [erlang-questions] {tls_alert,"handshake failure"} In-Reply-To: References: Message-ID: OTP 17 and OTP 17.4 I solved it by passing {depth,2} option, but it still seems strange to me that google.com requires that option also and error message is incoherent an unrelated to the certificate check error. > 3 ????? 2015 ?., ? 14:32, Lukas Winkler ???????(?): > > what erlang version are you running on? > > On 2 March 2015 at 21:46, Alex Hudich wrote: >> Hi >> >> I?ve got some strange errors when I try to make SSL connection to a web-site with peer verification on. >> >> Here?s an example: >> >> I?ve downloaded PEM certificates from https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt >> >> Then I start erl and run a command ssl:start(). >> >> Then I try to connect somewhere (I renamed ca-bundle.crt file to a cacert.pem): >> >> 2> ssl:connect( "t.ileads.ru", 443, [{verify,verify_peer},{cacertfile,"cacert.pem"}]). >> >> =ERROR REPORT==== 2-Mar-2015::23:32:15 === >> SSL: certify: ssl_handshake.erl:1403:Fatal error: handshake failure >> {error,{tls_alert,"handshake failure"}} >> >> >> Without peer verification everything went ok. >> >> What?s wrong? Or maybe I do something wrong? >> >> -- >> cul8er, Alex. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdelapena@REDACTED Wed Mar 4 00:19:02 2015 From: rdelapena@REDACTED (=?utf-8?Q?Jose_Ruben_de_la_Pe=C3=B1a?=) Date: Tue, 3 Mar 2015 17:19:02 -0600 Subject: [erlang-questions] Erlang 17.4 Issue regarding crypto Message-ID: Hello, i have erlang 17.4 and yaws 1.98 then when i run my application im getting next crash: =ERROR REPORT==== 1-Mar-2015::11:58:42 === Unable to load crypto library. Failed with error: "load_failed, Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.4.2/priv/lib/crypto.so: undefined symbol: AES_cfb8_encrypt'" OpenSSL might not be installed on this system. additionally: i have also cents 4.5 (64 bis) and OpenSSL 0.9.8ze Do you know if this issue still hot for erlang 17.4 release ??? i saw there are some threads regarding erlang 16 actually i tried to test solution but still im getting the same crash. Regards Jose Ruben de la Pe?a rdelapena@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From posilva@REDACTED Wed Mar 4 01:48:27 2015 From: posilva@REDACTED (Pedro Marques da Silva) Date: Wed, 4 Mar 2015 00:48:27 +0000 Subject: [erlang-questions] inet setoptions after receive data Message-ID: Hi Erlangers, I am doing a server to serve a flash application. When a flash client establish a connection(tcp socket) it sends a policy request (xml format message) and the server must reply with a policy file (xml file). After this exchange the client can connect to the socket as a regular connection. When I accept the connection the socket have a {packet,0} option set and checks if is a policy request and sends the policy file back. After this I change the option to {packet,4} but I do not receive anymore data. If I stay with {packet,0} I will receive the binary data sent by the client Any one knows about any problem with changing socket options after receive some data? thanks -- Pedro Marques da Silva --------------------------------------------------- E-mail Pessoal : posilva@REDACTED --------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Wed Mar 4 11:21:31 2015 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 4 Mar 2015 11:21:31 +0100 Subject: [erlang-questions] Yet Another MNESIA net split recover question In-Reply-To: References: Message-ID: <6CCF2C8C-024B-41EB-B7B5-17B1C27E2901@feuerlabs.com> > On 03 Mar 2015, at 21:32, Roberto Ostinelli wrote: > > I've seen in Ulf's unsplit that the function mnesia_controller:connect_nodes/2 is used to reconnect nodes. However, I cannot find any documentation for this function and I wander if that would be a good option. > > Any idea on how to reconnect nodes and have mnesia act "normal" again after a partitioned event without stopping/starting it? That function was actually added in order to make unsplit work, but as you?ve noted, it?s not part of the documented API. If it works for unsplit, it ought to work for you, but another option would be to actually use unsplit, distancing yourself one step from the use of an undocumented function. ;-) BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Wed Mar 4 11:49:41 2015 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 4 Mar 2015 11:49:41 +0100 Subject: [erlang-questions] Design patterns? In-Reply-To: References: Message-ID: <8CDA8215-6250-449A-9D7B-D4FC0F073415@feuerlabs.com> > On 02 Mar 2015, at 20:20, Judson Lester wrote: > > And an open question (for me): when to use case/if versus function heads? Roughly, I've been using cases to reformat the returns of a function call, but the decision trips me up every time. There is a consideration worth noting that can affect this decision: While you can?t trace on a given case expression, you *can* trace a function call. In general, I very much agree with Richard O?Keefe: you should choose whatever best communicates your intent. However, and perhaps Anders Svensson (now on the OTP team) is one of the most extreme proponents of this view, breaking out things like local funs into separate functions, makes it much easier to debug. This is especially true in live real-time systems, where tracing is one of the few ways you *can* debug (hopefully) without making a mess of things. Now, Erlang does allow you to selectively trace on anonymous funs, in part since it translates them into actual functions using a consistent naming scheme, but only the nerdiest of Erlang programmers have actually memorized this scheme. So if the code looks like this (example from OTP?s ?diameter? application): merge_service(Opts, Svc) -> lists:foldl(fun ms/2, Svc, Opts). ms({applications, As}, #diameter_service{applications = Apps} = S) when is_list(As) -> ? insert_local_peer(SApps, T, LDict) -> lists:foldl(fun(A,D) -> ilp(A, T, D) end, LDict, SApps). ilp({Id, Alias}, {TC, SA}, LDict) -> ? - then you have no problems tracing the ?inner loop? function of e.g. a fold. (Note that in the second example, Anders uses an anonymous fun to include part of the environment.) From an aesthetic (i.e. communication) standpoint, I find it slightly unfortunate, but OTOH, when it?s consistently and competently done, I will agree that you reasonably quickly get used to ?decoding? the style. For those who want to judge whether it?s a technique they want to adopt, I recommend reading the diameter sources, where it *is* pretty consistently applied. BR, Ulf Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Wed Mar 4 11:56:10 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Wed, 4 Mar 2015 11:56:10 +0100 Subject: [erlang-questions] unexpected message {error, closed} on passive SSL socket In-Reply-To: References: Message-ID: Here is some code to reproduce the issue. https://github.com/benoitc/test_ssl We get the {error, closed} from time to time in the worker: https://github.com/benoitc/test_ssl/blob/master/apps/test_ssl/src/test_ssl_worker.erl#L34 Let me know if you need more tests. - benoit On Tue, Mar 3, 2015 at 11:23 PM, Benoit Chesneau wrote: > Hi all, > > When closing a passive SSL socket ({active, false}) I get an unexpected > message `{error, closed}` in the process on Erlang 17.4 is this a known > issue? The SSL socket is connected with the following SSL options: > > > [{verify, verify_none}, {reuse_sessions, true}]; > > And the other inets options: > > [binary, {active, false}, {packet, raw}], > > > Any idea? > > - benoit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Wed Mar 4 12:25:16 2015 From: radek@REDACTED (Rad Gruchalski) Date: Wed, 4 Mar 2015 12:25:16 +0100 Subject: [erlang-questions] inet setoptions after receive data In-Reply-To: References: Message-ID: <8E7DBA0859BD483F81AEF4A69653BFDB@gruchalski.com> Hi Pedro, You should have a look at inet:setopts http://www.erlang.org/doc/man/inet.html#setopts-2 Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Wednesday, 4 March 2015 at 01:48, Pedro Marques da Silva wrote: > Hi Erlangers, > > I am doing a server to serve a flash application. When a flash client establish a connection(tcp socket) it sends a policy request (xml format message) and the server must reply with a policy file (xml file). After this exchange the client can connect to the socket as a regular connection. > > > When I accept the connection the socket have a {packet,0} option set and checks if is a policy request and sends the policy file back. After this I change the option to {packet,4} but I do not receive anymore data. If I stay with {packet,0} I will receive the binary data sent by the client > > > Any one knows about any problem with changing socket options after receive some data? > > thanks > -- > Pedro Marques da Silva > --------------------------------------------------- > E-mail Pessoal : posilva@REDACTED (mailto:posilva@REDACTED) > --------------------------------------------------- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.koener@REDACTED Wed Mar 4 13:00:38 2015 From: antoine.koener@REDACTED (Antoine Koener) Date: Wed, 4 Mar 2015 13:00:38 +0100 Subject: [erlang-questions] Erlang 17.4 Issue regarding crypto In-Reply-To: References: Message-ID: <713CFDBA-E6B7-4A92-A34F-132291D896AE@gmail.com> Hello, It seems to me that the problem is the version of OpenSSL which is quite old. > i have also cents 4.5 (64 bis) and OpenSSL 0.9.8ze crypto.so is trying to map the AES_cfb8_encrypt that you're openssl seems not to provide... > Le 4 mars 2015 ? 00:19, Jose Ruben de la Pe?a a ?crit : > > Hello, > > i have erlang 17.4 and yaws 1.98 then when i run my application im getting next crash: > > =ERROR REPORT==== 1-Mar-2015::11:58:42 === > Unable to load crypto library. Failed with error: > "load_failed, Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.4.2/priv/lib/crypto.so: undefined symbol: AES_cfb8_encrypt'" > OpenSSL might not be installed on this system. > > additionally: > i have also cents 4.5 (64 bis) and OpenSSL 0.9.8ze > > Do you know if this issue still hot for erlang 17.4 release ??? i saw there are some threads regarding erlang 16 actually i tried to test solution but still im getting the same crash. > > > Regards > > Jose Ruben de la Pe?a > rdelapena@REDACTED > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Wed Mar 4 13:08:13 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Wed, 4 Mar 2015 13:08:13 +0100 Subject: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory In-Reply-To: References: <20150128161934.GB90397@ferdair.local> <360A6593-9F4C-4695-B012-9373A404567F@widetag.com> <93FF5FD5-B802-4B7E-ACA2-CF717892A3B5@widetag.com> <54EEF2CA.80107@ninenines.eu> Message-ID: On Thu, Feb 26, 2015 at 12:56 PM, Roberto Ostinelli wrote: > Ah yes, indeed. The SSL processes I keep forgetting about. > I'm tempted to do another run with this option in. > > Did you have any success with it? In our own tests it just mitigate the issue for some times, but it is still growing over the time. - benoit > > > On Thu, Feb 26, 2015 at 11:17 AM, Lo?c Hoguin wrote: > >> He makes a good point, you are using hibernate yes, but that doesn't >> hibernate SSL processes themselves. With hibernate_after the SSL processes >> would hibernate too. >> >> Not sure if that would solve anything though, and SSL can probably be >> made more stable without the need to hibernate, which has a cost on its own. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Wed Mar 4 15:44:39 2015 From: radek@REDACTED (Radoslaw Gruchalski) Date: Wed, 4 Mar 2015 14:44:39 +0000 (UTC) Subject: [erlang-questions] inet setoptions after receive data In-Reply-To: References: <8E7DBA0859BD483F81AEF4A69653BFDB@gruchalski.com> Message-ID: What's the reason for changing the option in the first place? Why not to stick to {packet,0}? Sent from Outlook On Wed, Mar 4, 2015 at 6:40 AM -0800, "Pedro Marques da Silva" wrote: Hi,? I have looked before I post the question and is not clear why this will happen. Maybe is not possible to switch from {packet,0} to {packet,4} after receiving data on a socket! Best pms -- Pedro Marques da Silva --------------------------------------------------- E-mail Pessoal : posilva@REDACTED --------------------------------------------------- 2015-03-04 11:25 GMT+00:00 Rad Gruchalski : Hi Pedro, You should have a look at inet:setoptshttp://www.erlang.org/doc/man/inet.html#setopts-2 Kind regards, Radek Gruchalski radek@REDACTED de.linkedin.com/in/radgruchalski/ Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Wednesday, 4 March 2015 at 01:48, Pedro Marques da Silva wrote: Hi Erlangers, I am doing a server to serve a flash application. When a flash client establish a connection(tcp socket) it sends a policy request (xml format message) and the server must reply with a policy file (xml file). After this exchange the client can connect to the socket as a regular connection. When I accept the connection the socket have a {packet,0} option set and checks if is a policy request and sends the policy file back. After this I change the option to {packet,4} but I do not receive anymore data. If I stay with {packet,0} I will receive the binary data sent by the client Any one knows about any problem with changing socket options after receive some data? thanks -- Pedro Marques da Silva --------------------------------------------------- E-mail Pessoal : posilva@REDACTED --------------------------------------------------- _______________________________________________erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Wed Mar 4 16:06:20 2015 From: sean@REDACTED (Sean Cribbs) Date: Wed, 4 Mar 2015 09:06:20 -0600 Subject: [erlang-questions] Design patterns? In-Reply-To: <8CDA8215-6250-449A-9D7B-D4FC0F073415@feuerlabs.com> References: <8CDA8215-6250-449A-9D7B-D4FC0F073415@feuerlabs.com> Message-ID: I think the other argument for more functions over case expressions, which Garrett Smith has given quite convincingly in a number of media [1] [2], is that by naming things, you communicate meaning and increase clarity. Maybe the code gets "longer", but each component has a very specific purpose that is more obvious. I've found lately -- and apologies to my coworkers who have to suffer code reviews from me -- that like Ulf shows, I eschew anonymous functions except when they are only one expression inside the fun, or simply call some other function while capturing the environment. Another thing I've been finding a distaste for is manual recursion over lists, where the same algorithm could be expressed more simply with one of the HOFs in the lists module. I feel using the lists module increases clarity for the next person to read the code, and naming the per-item function does the same. If you are wondering about design patterns around concurrency, obviously OTP provides a lot of those, but there are some others that aren't part of the distribution. I'd suggest checking out Jay Nelson's epocxy [3] and gen_stream [4], Garrett's e2 [5], and of course the classics like gen_leader [6], riak_core [7] and various process pools [8] [9]. [1] http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html [2] https://www.youtube.com/watch?v=CQyt9Vlkbis [3] https://github.com/duomark/epocxy [4] https://github.com/duomark/gen_stream [5] http://e2project.org/ [6] https://github.com/KirinDave/gen_leader_revival [7] https://github.com/basho/riak_core [8] https://github.com/devinus/poolboy [9] https://github.com/seth/pooler On Wed, Mar 4, 2015 at 4:49 AM, Ulf Wiger wrote: > > On 02 Mar 2015, at 20:20, Judson Lester wrote: > > And an open question (for me): when to use case/if versus function heads? > Roughly, I've been using cases to reformat the returns of a function call, > but the decision trips me up every time. > > > There is a consideration worth noting that can affect this decision: > > While you can?t trace on a given case expression, you *can* trace a > function call. > > In general, I very much agree with Richard O?Keefe: you should choose > whatever best communicates your intent. > > However, and perhaps Anders Svensson (now on the OTP team) is one of the > most extreme proponents of this view, breaking out things like local funs > into separate functions, makes it much easier to debug. This is especially > true in live real-time systems, where tracing is one of the few ways you > *can* debug (hopefully) without making a mess of things. > > Now, Erlang does allow you to selectively trace on anonymous funs, in part > since it translates them into actual functions using a consistent naming > scheme, but only the nerdiest of Erlang programmers have actually memorized > this scheme. So if the code looks like this (example from OTP?s ?diameter? > application): > > merge_service(Opts, Svc) -> > lists:foldl(fun ms/2, Svc, Opts). > > ms({applications, As}, #diameter_service{applications = Apps} = S) > when is_list(As) -> > > ? > > insert_local_peer(SApps, T, LDict) -> > lists:foldl(fun(A,D) -> ilp(A, T, D) end, LDict, SApps). > > ilp({Id, Alias}, {TC, SA}, LDict) -> > ? > > - then you have no problems tracing the ?inner loop? function of e.g. a > fold. > > (Note that in the second example, Anders uses an anonymous fun to include > part of the environment.) > > From an aesthetic (i.e. communication) standpoint, I find it slightly > unfortunate, but OTOH, when it?s consistently and competently done, I will > agree that you reasonably quickly get used to ?decoding? the style. > > For those who want to judge whether it?s a technique they want to adopt, I > recommend reading the diameter sources, where it *is* pretty consistently > applied. > > BR, > Ulf > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Sean Cribbs Sr. Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From MChenini@REDACTED Wed Mar 4 16:32:11 2015 From: MChenini@REDACTED (Chenini, Mohamed) Date: Wed, 4 Mar 2015 15:32:11 +0000 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> Message-ID: Hi, You should follow Fred Hebert path who made his ebook ?STUFF GOES BAD: ERLANG IN ANGER" free to download. Regards, Mohamed From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Jesse Gumm Sent: Tuesday, March 03, 2015 6:42 PM To: Zachary Kessin Cc: Erlang Questions Subject: Re: [erlang-questions] New Erlang EBook Awesome! Thanks for sharing, Zach, I'll definitely be checking this out. -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm On Mar 3, 2015 5:07 AM, "Zachary Kessin" > wrote: Hi everyone, I have just put out a new Ebook on Using QuickCheck on Erlang. It covers all three major erlang QuickCheck versions (Quviq, PropEr, and Triq). and will take you from your first property to being a QuickCheck master. Right now it is in Early Release. The content is being developed and it should be finished by Erlang Factory SF. If you buy it today you will get all the updates as I work on it http://www.erlang-quickcheck-book.com/ -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Wed Mar 4 16:35:05 2015 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Wed, 4 Mar 2015 16:35:05 +0100 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> Message-ID: You should follow *Fred Hebert* path who made his ebook ?*STUFF GOES BAD: ERLANG IN ANGER"* *free* to download. Why? On Wed, Mar 4, 2015 at 4:32 PM, Chenini, Mohamed wrote: > Hi, > > > > You should follow *Fred Hebert* path who made his ebook ?*STUFF GOES BAD: > ERLANG IN ANGER"* *free* to download. > > > > Regards, > > Mohamed > > > > > > *From:* erlang-questions-bounces@REDACTED [mailto: > erlang-questions-bounces@REDACTED] *On Behalf Of *Jesse Gumm > *Sent:* Tuesday, March 03, 2015 6:42 PM > *To:* Zachary Kessin > *Cc:* Erlang Questions > *Subject:* Re: [erlang-questions] New Erlang EBook > > > > Awesome! > > Thanks for sharing, Zach, I'll definitely be checking this out. > > -- > Jesse Gumm > Owner, Sigma Star Systems > 414.940.4866 || sigma-star.com || @jessegumm > > On Mar 3, 2015 5:07 AM, "Zachary Kessin" wrote: > > Hi everyone, > > I have just put out a new Ebook on Using QuickCheck on Erlang. It covers > all three major erlang QuickCheck versions (Quviq, PropEr, and Triq). and > will take you from your first property to being a QuickCheck master. > > Right now it is in Early Release. The content is being developed and it > should be finished by Erlang Factory SF. > > If you buy it today you will get all the updates as I work on it > > http://www.erlang-quickcheck-book.com/ > > -- > Zachary Kessin > Mostly Erlang Podcast > Skype: zachkessin > Twitter: @zkessin > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > ==================== > This email/fax message is for the sole use of the intended > recipient(s) and may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution of this > email/fax is prohibited. If you are not the intended recipient, please > destroy all paper and electronic copies of the original message. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Mark Nijhof K64 m: 0047 46748688 t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From posilva@REDACTED Wed Mar 4 15:40:07 2015 From: posilva@REDACTED (Pedro Marques da Silva) Date: Wed, 4 Mar 2015 14:40:07 +0000 Subject: [erlang-questions] inet setoptions after receive data In-Reply-To: <8E7DBA0859BD483F81AEF4A69653BFDB@gruchalski.com> References: <8E7DBA0859BD483F81AEF4A69653BFDB@gruchalski.com> Message-ID: Hi, I have looked before I post the question and is not clear why this will happen. Maybe is not possible to switch from {packet,0} to {packet,4} after receiving data on a socket! Best pms -- Pedro Marques da Silva --------------------------------------------------- E-mail Pessoal : posilva@REDACTED --------------------------------------------------- 2015-03-04 11:25 GMT+00:00 Rad Gruchalski : > Hi Pedro, > > You should have a look at inet:setopts > http://www.erlang.org/doc/man/inet.html#setopts-2 > > Kind regards, > Radek Gruchalski > radek@REDACTED > de.linkedin.com/in/radgruchalski/ > > > *Confidentiality:*This communication is intended for the above-named > person and may be confidential and/or legally privileged. > If it has come to you in error you must take no action based on it, nor > must you copy or show it to anyone; please delete/destroy and inform the > sender immediately. > > On Wednesday, 4 March 2015 at 01:48, Pedro Marques da Silva wrote: > > Hi Erlangers, > > I am doing a server to serve a flash application. When a flash client > establish a connection(tcp socket) it sends a policy request (xml format > message) and the server must reply with a policy file (xml file). After > this exchange the client can connect to the socket as a regular connection. > > > When I accept the connection the socket have a {packet,0} option set and > checks if is a policy request and sends the policy file back. After this I > change the option to {packet,4} but I do not receive anymore data. If I > stay with {packet,0} I will receive the binary data sent by the client > > > Any one knows about any problem with changing socket options after receive > some data? > > thanks > -- > Pedro Marques da Silva > --------------------------------------------------- > E-mail Pessoal : posilva@REDACTED > --------------------------------------------------- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdelapena@REDACTED Wed Mar 4 16:05:55 2015 From: rdelapena@REDACTED (=?utf-8?Q?Jose_Ruben_de_la_Pe=C3=B1a?=) Date: Wed, 4 Mar 2015 09:05:55 -0600 Subject: [erlang-questions] Erlang 17.4 Issue regarding crypto In-Reply-To: <713CFDBA-E6B7-4A92-A34F-132291D896AE@gmail.com> References: <713CFDBA-E6B7-4A92-A34F-132291D896AE@gmail.com> Message-ID: <62687D90-2F01-4B1C-8D54-40E24B5F3DB2@txmglobal.com> Thank you. what openssl do you recommend ?? Jose Ruben de la Pe?a rdelapena@REDACTED > On Mar 4, 2015, at 6:00 AM, Antoine Koener wrote: > > Hello, > > It seems to me that the problem is the version of OpenSSL which is quite old. > >> i have also cents 4.5 (64 bis) and OpenSSL 0.9.8ze > > > crypto.so is trying to map the AES_cfb8_encrypt that you're openssl seems not to provide... > >> Le 4 mars 2015 ? 00:19, Jose Ruben de la Pe?a > a ?crit : >> >> Hello, >> >> i have erlang 17.4 and yaws 1.98 then when i run my application im getting next crash: >> >> =ERROR REPORT==== 1-Mar-2015::11:58:42 === >> Unable to load crypto library. Failed with error: >> "load_failed, Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.4.2/priv/lib/crypto.so: undefined symbol: AES_cfb8_encrypt'" >> OpenSSL might not be installed on this system. >> >> additionally: >> i have also cents 4.5 (64 bis) and OpenSSL 0.9.8ze >> >> Do you know if this issue still hot for erlang 17.4 release ??? i saw there are some threads regarding erlang 16 actually i tried to test solution but still im getting the same crash. >> >> >> Regards >> >> Jose Ruben de la Pe?a >> rdelapena@REDACTED >> >> >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Wed Mar 4 16:47:42 2015 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Wed, 4 Mar 2015 16:47:42 +0100 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> Message-ID: I am sorry but I find these "suggestions" very annoying! So a few questions: - How much do you feel an hour of your time is worth? - How much should one hour of Zachs time be worth? - How long do you think it took to write this information down (let along gather it)? - How long do you think it will take yourself to gather the same information? - How much work do you do that others demand to be for free? If people want to give things to the community then that is awesome, but it should not be expected, also looking at the questions above, the potential in sales (Erlang is a small community) then $39 is practically giving it away already. Even this one: http://www.amazon.com/Handbook-Neuroevolution-Through-Erlang-Gene-ebook/dp/B00AKIFKJ8 is probably not expensive for what value you get. -Mark On Wed, Mar 4, 2015 at 4:35 PM, Mark Nijhof wrote: > You should follow *Fred Hebert* path who made his ebook ?*STUFF GOES BAD: > ERLANG IN ANGER"* *free* to download. > > Why? > > > On Wed, Mar 4, 2015 at 4:32 PM, Chenini, Mohamed > wrote: > >> Hi, >> >> >> >> You should follow *Fred Hebert* path who made his ebook ?*STUFF GOES >> BAD: ERLANG IN ANGER"* *free* to download. >> >> >> >> Regards, >> >> Mohamed >> >> >> >> >> >> *From:* erlang-questions-bounces@REDACTED [mailto: >> erlang-questions-bounces@REDACTED] *On Behalf Of *Jesse Gumm >> *Sent:* Tuesday, March 03, 2015 6:42 PM >> *To:* Zachary Kessin >> *Cc:* Erlang Questions >> *Subject:* Re: [erlang-questions] New Erlang EBook >> >> >> >> Awesome! >> >> Thanks for sharing, Zach, I'll definitely be checking this out. >> >> -- >> Jesse Gumm >> Owner, Sigma Star Systems >> 414.940.4866 || sigma-star.com || @jessegumm >> >> On Mar 3, 2015 5:07 AM, "Zachary Kessin" wrote: >> >> Hi everyone, >> >> I have just put out a new Ebook on Using QuickCheck on Erlang. It covers >> all three major erlang QuickCheck versions (Quviq, PropEr, and Triq). and >> will take you from your first property to being a QuickCheck master. >> >> Right now it is in Early Release. The content is being developed and it >> should be finished by Erlang Factory SF. >> >> If you buy it today you will get all the updates as I work on it >> >> http://www.erlang-quickcheck-book.com/ >> >> -- >> Zachary Kessin >> Mostly Erlang Podcast >> Skype: zachkessin >> Twitter: @zkessin >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> ==================== >> This email/fax message is for the sole use of the intended >> recipient(s) and may contain confidential and privileged information. >> Any unauthorized review, use, disclosure or distribution of this >> email/fax is prohibited. If you are not the intended recipient, please >> destroy all paper and electronic copies of the original message. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Mark Nijhof > K64 > m: 0047 46748688 > t: @MarkNijhof > s: marknijhof > > -- Mark Nijhof K64 m: 0047 46748688 t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Mar 4 16:50:24 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 04 Mar 2015 16:50:24 +0100 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> Message-ID: <54F729C0.1010607@ninenines.eu> From what I understand he published his ebook for free because Heroku allowed him to work on it on company time and didn't want him to profit from it. That's a tough act to follow. On 03/04/2015 04:32 PM, Chenini, Mohamed wrote: > Hi, > > You should follow *Fred Hebert* path who made his ebook ?*STUFF GOES > BAD: ERLANG IN ANGER"* *free* to download. > > Regards, > > Mohamed > > *From:*erlang-questions-bounces@REDACTED > [mailto:erlang-questions-bounces@REDACTED] *On Behalf Of *Jesse Gumm > *Sent:* Tuesday, March 03, 2015 6:42 PM > *To:* Zachary Kessin > *Cc:* Erlang Questions > *Subject:* Re: [erlang-questions] New Erlang EBook > > Awesome! > > Thanks for sharing, Zach, I'll definitely be checking this out. > > -- > Jesse Gumm > Owner, Sigma Star Systems > 414.940.4866 || sigma-star.com || @jessegumm > > On Mar 3, 2015 5:07 AM, "Zachary Kessin" > wrote: > > Hi everyone, > > I have just put out a new Ebook on Using QuickCheck on Erlang. It covers > all three major erlang QuickCheck versions (Quviq, PropEr, and Triq). > and will take you from your first property to being a QuickCheck master. > > Right now it is in Early Release. The content is being developed and it > should be finished by Erlang Factory SF. > > If you buy it today you will get all the updates as I work on it > > http://www.erlang-quickcheck-book.com/ > > -- > Zachary Kessin > Mostly Erlang Podcast > Skype: zachkessin > Twitter: @zkessin > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > ==================== > This email/fax message is for the sole use of the intended > recipient(s) and may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution of this > email/fax is prohibited. If you are not the intended recipient, please > destroy all paper and electronic copies of the original message. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From roberto@REDACTED Wed Mar 4 16:55:49 2015 From: roberto@REDACTED (Roberto Ostinelli) Date: Wed, 4 Mar 2015 16:55:49 +0100 Subject: [erlang-questions] Yet Another MNESIA net split recover question In-Reply-To: <6CCF2C8C-024B-41EB-B7B5-17B1C27E2901@feuerlabs.com> References: <6CCF2C8C-024B-41EB-B7B5-17B1C27E2901@feuerlabs.com> Message-ID: Using unsplit was the original intent :) However, my case is much simpler, I do not need to solve conflicts. The only thing I really need is to: - Take what is on NodeA and add it to NodeB's table - Take what is on NodeB and add it to NodeA's table I took most of the unsplit code and heavily simplified it to my case :) Thank you Ulf, r. On Wed, Mar 4, 2015 at 11:21 AM, Ulf Wiger wrote: > > On 03 Mar 2015, at 21:32, Roberto Ostinelli wrote: > > I've seen in Ulf's unsplit that the function > mnesia_controller:connect_nodes/2 is used to reconnect nodes. However, I > cannot find any documentation for this function and I wander if that would > be a good option. > > Any idea on how to reconnect nodes and have mnesia act "normal" again > after a partitioned event without stopping/starting it? > > > That function was actually added in order to make unsplit work, but as > you?ve noted, it?s not part of the documented API. > > If it works for unsplit, it ought to work for you, but another option > would be to actually use unsplit, distancing yourself one step from the use > of an undocumented function. ;-) > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Wed Mar 4 16:56:45 2015 From: roberto@REDACTED (Roberto Ostinelli) Date: Wed, 4 Mar 2015 16:56:45 +0100 Subject: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory In-Reply-To: References: <20150128161934.GB90397@ferdair.local> <360A6593-9F4C-4695-B012-9373A404567F@widetag.com> <93FF5FD5-B802-4B7E-ACA2-CF717892A3B5@widetag.com> <54EEF2CA.80107@ninenines.eu> Message-ID: Yes. It stabilized impressively the whole thing. I also tried HAproxy (single CPU), and stud. Both were far from being able to handle the load that I'm throwing at them. I mean, *far*. Best, r. On Wed, Mar 4, 2015 at 1:08 PM, Benoit Chesneau wrote: > > > On Thu, Feb 26, 2015 at 12:56 PM, Roberto Ostinelli > wrote: > >> Ah yes, indeed. The SSL processes I keep forgetting about. >> I'm tempted to do another run with this option in. >> >> > Did you have any success with it? In our own tests it just mitigate the > issue for some times, but it is still growing over the time. > > - benoit > >> >> >> On Thu, Feb 26, 2015 at 11:17 AM, Lo?c Hoguin wrote: >> >>> He makes a good point, you are using hibernate yes, but that doesn't >>> hibernate SSL processes themselves. With hibernate_after the SSL processes >>> would hibernate too. >>> >>> Not sure if that would solve anything though, and SSL can probably be >>> made more stable without the need to hibernate, which has a cost on its own. >> >> >> _______________________________________________ >> 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 Wed Mar 4 17:33:21 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 4 Mar 2015 11:33:21 -0500 Subject: [erlang-questions] New Erlang EBook In-Reply-To: <54F729C0.1010607@ninenines.eu> References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> Message-ID: <20150304163319.GB57078@ferdair.local> On 03/04, Lo?c Hoguin wrote: > From what I understand he published his ebook for free because Heroku > allowed him to work on it on company time and didn't want him to profit from > it. > This is correct. Part of the manual had been started before in my free time, but to finish it I got to negotiate and bring it under the Heroku umbrella. It was a move for the community, so profit from it was out of the question. I personally always aim for what I write to be free (as in beer) -- if I can't find the time, there just will be less content. Various authors have different priorities, values, choices, schedules, financial situations, jobs, and family lives. The side-benefits of writing books (reputation, conference invitations, job offers, meeting people, braggin rights, etc.) also apply differently depending on where you are, both geographically and in your life. Some authors will hire editors, copy-editors, reviewers, etc. while others won't. It's no surprise they may prefer other routes than free copies, and we should all be okay with that. They're the ones putting in the work, and we're the ones benefitting from it. If Zach wishes to charge money for his book, that's his prerogative. He's written before and is likely aware of the consequences (Will readers expense it at work, pirate it at home, borrow it from a library? Does pricing change the perception people have from the book in terms of quality?) and able to choose what he's comfortable with. Regards, Fred. From rr@REDACTED Wed Mar 4 18:12:23 2015 From: rr@REDACTED (Rick Reed) Date: Wed, 4 Mar 2015 17:12:23 +0000 Subject: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory In-Reply-To: References: <20150128161934.GB90397@ferdair.local> <360A6593-9F4C-4695-B012-9373A404567F@widetag.com> <93FF5FD5-B802-4B7E-ACA2-CF717892A3B5@widetag.com> <54EEF2CA.80107@ninenines.eu> Message-ID: Interesting. What kind of load were you throwing at stud that it couldn?t handle? We terminate all our SSL using stud. We easily do >2000 handshakes per second and as much as 8Gb/s per server. Granted, these are pretty beefy boxes, but the only part of the stud setup that doesn?t scale for us is when we?re trying to scale up past 1.5M external connections (which means 4.5M sockets). Rr From: Roberto Ostinelli > Date: Wednesday, March 4, 2015 at 7:56 AM To: Benoit Chesneau > Cc: Erlang Questions > Subject: Re: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory Yes. It stabilized impressively the whole thing. I also tried HAproxy (single CPU), and stud. Both were far from being able to handle the load that I'm throwing at them. I mean, *far*. Best, r. On Wed, Mar 4, 2015 at 1:08 PM, Benoit Chesneau > wrote: On Thu, Feb 26, 2015 at 12:56 PM, Roberto Ostinelli > wrote: Ah yes, indeed. The SSL processes I keep forgetting about. I'm tempted to do another run with this option in. Did you have any success with it? In our own tests it just mitigate the issue for some times, but it is still growing over the time. - benoit On Thu, Feb 26, 2015 at 11:17 AM, Lo?c Hoguin > wrote: He makes a good point, you are using hibernate yes, but that doesn't hibernate SSL processes themselves. With hibernate_after the SSL processes would hibernate too. Not sure if that would solve anything though, and SSL can probably be made more stable without the need to hibernate, which has a cost on its own. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.ostinelli@REDACTED Wed Mar 4 19:22:45 2015 From: roberto.ostinelli@REDACTED (Roberto Ostinelli) Date: Wed, 4 Mar 2015 19:22:45 +0100 Subject: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory In-Reply-To: References: <20150128161934.GB90397@ferdair.local> <360A6593-9F4C-4695-B012-9373A404567F@widetag.com> <93FF5FD5-B802-4B7E-ACA2-CF717892A3B5@widetag.com> <54EEF2CA.80107@ninenines.eu> Message-ID: <17070BB5-C8CC-4573-B92F-FC9A52CD9729@widetag.com> > On 04/mar/2015, at 18:12, Rick Reed wrote: > > Interesting. What kind of load were you throwing at stud that it couldn?t handle? We terminate all our SSL using stud. We easily do >2000 handshakes per second and as much as 8Gb/s per server. Granted, these are pretty beefy boxes, but the only part of the stud setup that doesn?t scale for us is when we?re trying to scale up past 1.5M external connections (which means 4.5M sockets). > > Rr Hi Rick, I didn't use a separate box for SSL termination with stud. I basically wanted to see if stud could offload SSL from my Erlang application, so I just set my app to run in non-ssl mode, and had stud handle the SSL frontend on the same box. On a single Erlang box with SSL-enabled I handle around 180k always-connected devices, each sending heartbeats every minute, plus around 4k/s short-lived incoming https requests. Sure, I'd be better off having stud on a separate box, but I'd rather have 2 Erlang boxes than 1 Erlang + 1 stud box. Also, I read on stud's readme file that every connection has a 200k bytes overhead. Erlang uses around 8GB for everything so stud's ram consumption is order of magnitude higher for my 180k online + 20k short-lived connections (unless I mis-read that info). Anything you believe I should try? Best, r. From eriksoe@REDACTED Wed Mar 4 20:52:25 2015 From: eriksoe@REDACTED (=?UTF-8?Q?Erik_S=C3=B8e_S=C3=B8rensen?=) Date: Wed, 4 Mar 2015 20:52:25 +0100 Subject: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory In-Reply-To: References: <20150128161934.GB90397@ferdair.local> <360A6593-9F4C-4695-B012-9373A404567F@widetag.com> <93FF5FD5-B802-4B7E-ACA2-CF717892A3B5@widetag.com> <54EEF2CA.80107@ninenines.eu> Message-ID: Good to hear. Although... Graphs or it didn't happen? :-) Den 04/03/2015 16.57 skrev "Roberto Ostinelli" : > Yes. > It stabilized impressively the whole thing. > > I also tried HAproxy (single CPU), and stud. Both were far from being able > to handle the load that I'm throwing at them. I mean, *far*. > > Best, > r. > > On Wed, Mar 4, 2015 at 1:08 PM, Benoit Chesneau > wrote: > >> >> >> On Thu, Feb 26, 2015 at 12:56 PM, Roberto Ostinelli >> wrote: >> >>> Ah yes, indeed. The SSL processes I keep forgetting about. >>> I'm tempted to do another run with this option in. >>> >>> >> Did you have any success with it? In our own tests it just mitigate the >> issue for some times, but it is still growing over the time. >> >> - benoit >> >>> >>> >>> On Thu, Feb 26, 2015 at 11:17 AM, Lo?c Hoguin >>> wrote: >>> >>>> He makes a good point, you are using hibernate yes, but that doesn't >>>> hibernate SSL processes themselves. With hibernate_after the SSL processes >>>> would hibernate too. >>>> >>>> Not sure if that would solve anything though, and SSL can probably be >>>> made more stable without the need to hibernate, which has a cost on its own. >>> >>> >>> _______________________________________________ >>> 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 roberto@REDACTED Wed Mar 4 21:03:44 2015 From: roberto@REDACTED (Roberto Ostinelli) Date: Wed, 4 Mar 2015 21:03:44 +0100 Subject: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory In-Reply-To: References: <20150128161934.GB90397@ferdair.local> <360A6593-9F4C-4695-B012-9373A404567F@widetag.com> <93FF5FD5-B802-4B7E-ACA2-CF717892A3B5@widetag.com> <54EEF2CA.80107@ninenines.eu> Message-ID: Here you go: https://cldup.com/HuM2vX3xsh-3000x3000.png ^^_ r. On Wed, Mar 4, 2015 at 8:52 PM, Erik S?e S?rensen wrote: > Good to hear. > Although... Graphs or it didn't happen? :-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rr@REDACTED Wed Mar 4 22:30:14 2015 From: rr@REDACTED (Rick Reed) Date: Wed, 4 Mar 2015 21:30:14 +0000 Subject: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory In-Reply-To: <17070BB5-C8CC-4573-B92F-FC9A52CD9729@widetag.com> References: <20150128161934.GB90397@ferdair.local> <360A6593-9F4C-4695-B012-9373A404567F@widetag.com> <93FF5FD5-B802-4B7E-ACA2-CF717892A3B5@widetag.com> <54EEF2CA.80107@ninenines.eu> <17070BB5-C8CC-4573-B92F-FC9A52CD9729@widetag.com> Message-ID: On 3/4/15, 10:22 AM, "Roberto Ostinelli" wrote: >I didn't use a separate box for SSL termination with stud. I basically >wanted to see if stud could offload SSL from my Erlang application, so I >just set my app to run in non-ssl mode, and had stud handle the SSL >frontend on the same box. That?s exactly what we do. >Also, I read on stud's readme file that every connection has a 200k bytes >overhead. We patched a config option to reduce the size of the per-conn buffer space (from 96k). On one service, we run 4K buffering per user. Rr From roger@REDACTED Thu Mar 5 12:50:40 2015 From: roger@REDACTED (Roger Lipscombe) Date: Thu, 5 Mar 2015 11:50:40 +0000 Subject: [erlang-questions] New Erlang EBook In-Reply-To: <20150304163319.GB57078@ferdair.local> References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: > If Zach wishes to charge money for his book, that's his prerogative. > He's written before and is likely aware of the consequences (Will > readers expense it at work, pirate it at home, borrow it from a library? > Does pricing change the perception people have from the book in terms of > quality?) and able to choose what he's comfortable with. Absolutely agree with this. It is totally Zach's prerogative. Doesn't make me stop wishing that there was a sample chapter available for free, though. $39 seems like a lot to plunk down sight unseen. For this reason alone, I'll be holding back. Contrast this with the fact that I just this morning bought "Your Code As a Crime Scene" from Pragpub based on reading a couple of sample pages. From mark.nijhof@REDACTED Thu Mar 5 12:54:57 2015 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Thu, 5 Mar 2015 12:54:57 +0100 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: This is much more constructive feedback, you are basically saying what is holding you back from buying vs wanting to get it for free. The argument was never about what an author does, just that what they decided to do to be respected. On Thu, Mar 5, 2015 at 12:50 PM, Roger Lipscombe wrote: > > If Zach wishes to charge money for his book, that's his prerogative. > > He's written before and is likely aware of the consequences (Will > > readers expense it at work, pirate it at home, borrow it from a library? > > Does pricing change the perception people have from the book in terms of > > quality?) and able to choose what he's comfortable with. > > Absolutely agree with this. It is totally Zach's prerogative. Doesn't > make me stop wishing that there was a sample chapter available for > free, though. $39 seems like a lot to plunk down sight unseen. For > this reason alone, I'll be holding back. > > Contrast this with the fact that I just this morning bought "Your Code > As a Crime Scene" from Pragpub based on reading a couple of sample > pages. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Mark Nijhof K64 m: 0047 46748688 t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From community-manager@REDACTED Thu Mar 5 15:39:27 2015 From: community-manager@REDACTED (Bruce Yinhe) Date: Thu, 5 Mar 2015 15:39:27 +0100 Subject: [erlang-questions] New Erlang job openings Message-ID: Hi, Erlang Central has currently 33 Erlang-related job openings. https://erlangcentral.org/jobs To publish new Erlang jobs free of charge: https://erlangcentral.org/jobs/add To subscribe for weekly updates on new Erlang jobs - Register on Erlang Central. https://erlangcentral.org/login/?action=register *Europe:* Erlang Developer (Junior/Senior) at Erlang Solutions - London, Budapest, Krakow, Stockholm https://erlangcentral.org/erlang-developer-erlang-solutions/ UK Home Based Role - Middleware Developer at bet365 - Stoke-on-Trent, UK https://erlangcentral.org/uk-home-based-role-middleware-developer-bet365/ Software Engineer at Ubiquiti Networks - Krakow, Poland https://erlangcentral.org/software-engineer-ubiquiti-networks/ Erlang Developer at Klarna - Stockholm, Sweden https://erlangcentral.org/erlang-developer-klarna/ Erlang developer at IoP - anywhere https://erlangcentral.org/erlang-developer-ambitious-startup-internet-of-people/ Software Engineer at Alert Logic - Cardiff, UK https://erlangcentral.org/software-engineer-alert-logic/ Erlang Software Developers at AccionLabs - London, UK https://erlangcentral.org/erlang-software-developers-accionlabs/ Erlang Developer at Darwin Recruitment - London, UK https://erlangcentral.org/erlang-developer-darwin-recruitment/ Erlang Developer (competitive salary with stock options) at Expend.io - London, UK https://erlangcentral.org/erlang -developer-competitive-salary-with-stock-options-expend-io/ Senior Back-end Engineer at Spatch - London, UK https://erlangcentral.org/senior-back-end-engineer-spatch/ Senior DevOps Engineer at Spatch - London, UK https://erlangcentral.org/senior-devops-engineer-spatch/ Backend Functional Software Engineer at Guardtime - UK https://erlangcentral.org/backend-functional-software-engineer-guardtime/ Senior Engineer with DevOps Focus at Campanja - Stockholm, Sweden https://erlangcentral.org/senior-engineer-with-devops-focus-campanja/ Backend Engineer at Centralway - Zurich, Switzerland https://erlangcentral.org/backend-engineer-centralway/ Back-end Developer at NGTI - Rotterdam, The Netherlands https://erlangcentral.org/back-end-developer-ngti-nl/ *Americas:* Software Developer ? Home Based at Basho Technologies - Home Based https://erlangcentral.org/software-developer-home-based-basho/ Principal Software Engineer ? Home Based at Basho Technologies - Home Based https://erlangcentral.org/principal-software-engineer-home-based-basho/ Erlang Developer at Sqor Sports - San Francisco, CA https://erlangcentral.org/erlang-developer-sqor/ Erlang Developer at Inaka - Buenos Aires, Argentina https://erlangcentral.org/erlang-developer-inaka/ Lead Infrastructure and Erlang Engineer at Go Factory - San Francisco, CA https://erlangcentral.org/lead-infrastructure-and-erlang-engineer-go-factory/ Senior Staff & Lead Erlang Engineers at Raretec Consulting - California, CA https://erlangcentral.org/senior-staff-lead-erlang-engineers-raretec-consulting/ Lead Functional Programmer at Visa Inc. - Foster City, CA https://erlangcentral.org/visa-lead-functional-programmer/ Sr. Staff SW Engineer at Visa Inc. - Foster City, CA https://erlangcentral.org/sr-staff-sw-engineer-visa/ Sr. Software Engineer at SynapSense - Folsom, CA https://erlangcentral.org/sr-software-engineer-synapsense/ Backend Engineer at issuu - Palo Alto, CA https://erlangcentral.org/backend-engineer-issuu/ Senior Erlang Engineer at Machine Zone - Palo Alto, CA https://erlangcentral.org/senior-erlang-engineer-machine-zone/ Erlang Developer at INT Technologies - San Antonio, TX https://erlangcentral.org/erlang-int-technologies/ Elixir / Erlang Developer at Vitamin Talent - Austin, TX (open to remote) https://erlangcentral.org/elixir-erlang-developer-vitamin-talent/ *Asia & Oceania * System Analyst (Erlang software engineer) at Chaatz Limited - Wan Chai,Hong Kong https://erlangcentral.org/system-analyst-erlang-software-engineer-chaatz/ Best regards, Bruce Yinhe ErlangCentral.org -- Bruce Yinhe Erlang Community Manager Industrial Erlang User Group community-manager@REDACTED +46 72 311 43 89 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharrell-keyword-erlang.a034fe@REDACTED Thu Mar 5 16:51:39 2015 From: mharrell-keyword-erlang.a034fe@REDACTED (Matthew Harrell) Date: Thu, 5 Mar 2015 10:51:39 -0500 Subject: [erlang-questions] Reliable and unreliable SCTP Message-ID: <20150305155139.GA26027@bittwiddlers.com> Does the SCTP implementation in erlang 17.4 allow for both reliable and unreliable messages to be sent within a single association? Something like RFC 3758? It seems to mostly be reliable but it would be nice to have a way to tell it that some content wasn't as important From rdelapena@REDACTED Thu Mar 5 17:09:00 2015 From: rdelapena@REDACTED (=?utf-8?Q?Jose_Ruben_de_la_Pe=C3=B1a?=) Date: Thu, 5 Mar 2015 10:09:00 -0600 Subject: [erlang-questions] Erlang 17.4 Issue regarding crypto In-Reply-To: References: <713CFDBA-E6B7-4A92-A34F-132291D896AE@gmail.com> <62687D90-2F01-4B1C-8D54-40E24B5F3DB2@txmglobal.com> Message-ID: <0EA9BF07-3BDD-455F-B1CA-9A01BFB460D7@txmglobal.com> Hello Guys. with the update of Openssl to 1.0.2 its working. thank you very much for your support. $ openssl version OpenSSL 1.0.2 22 Jan 2015 my environment is: Centos 4.5 (64 bits), yaws 1.98, erlang 17.4 // Regards Jose Ruben de la Pe?a rdelapena@REDACTED > On Mar 4, 2015, at 7:10 PM, $$*???*$$ <81913811@REDACTED> wrote: > > Hello, > I think you can try to install the newest version of openssl or update openssl to newest version. > which OS and the openssl version do you use? > > > ------------------ ???? ------------------ > ???: "Jose Ruben de la Pe?a";; > ????: 2015?3?4?(???) ??11:05 > ???: "Antoine Koener"; > ??: "erlang-questions"; > ??: Re: [erlang-questions] Erlang 17.4 Issue regarding crypto > > Thank you. > > what openssl do you recommend ?? > > > Jose Ruben de la Pe?a > rdelapena@REDACTED > > > > > > > >> On Mar 4, 2015, at 6:00 AM, Antoine Koener > wrote: >> >> Hello, >> >> It seems to me that the problem is the version of OpenSSL which is quite old. >> >>> i have also cents 4.5 (64 bis) and OpenSSL 0.9.8ze >> >> >> crypto.so is trying to map the AES_cfb8_encrypt that you're openssl seems not to provide... >> >>> Le 4 mars 2015 ? 00:19, Jose Ruben de la Pe?a > a ?crit : >>> >>> Hello, >>> >>> i have erlang 17.4 and yaws 1.98 then when i run my application im getting next crash: >>> >>> =ERROR REPORT==== 1-Mar-2015::11:58:42 === >>> Unable to load crypto library. Failed with error: >>> "load_failed, Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.4.2/priv/lib/crypto.so: undefined symbol: AES_cfb8_encrypt'" >>> OpenSSL might not be installed on this system. >>> >>> additionally: >>> i have also cents 4.5 (64 bis) and OpenSSL 0.9.8ze >>> >>> Do you know if this issue still hot for erlang 17.4 release ??? i saw there are some threads regarding erlang 16 actually i tried to test solution but still im getting the same crash. >>> >>> >>> Regards >>> >>> Jose Ruben de la Pe?a >>> rdelapena@REDACTED >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kouzan@REDACTED Thu Mar 5 19:45:45 2015 From: kouzan@REDACTED (Antonis Kouzoupis) Date: Thu, 5 Mar 2015 19:45:45 +0100 Subject: [erlang-questions] Erlang - Java symmetric encryption Message-ID: <20150305184542.GA18321@earendil> Hi, I'm trying to build a system where mobile devices (Android) will communicate each other encrypted TCP messages and the symmetric key distribution will be handled by a server in Erlang. As an Erlang *newbie*, I've been confused with the key derivation and encryption/decryption. What I want is to produce the same key both in mobile (java) and in server (erlang), Supposedly that the salt is the same. I use the erlang-pbkdf2 [0] module to generate the key in server and bouncy castle in java. Also I use AES in CTR mode in both sides to encrypt/decrypt, again the IV is known to both sides. So far the decrypted ciphertext on server is not the same as the cleartext on mobile. Can you give me any hint on how to correctly produce the same key (password based) both in Erland and in Java? [0] https://github.com/whitelynx/erlang-pbkdf2 Thank you for your time, -- ??????? ????????? Antonis Kouzoupis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From ok@REDACTED Thu Mar 5 22:37:40 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 6 Mar 2015 10:37:40 +1300 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: Traditional publishing offers a number of things - advertising (sending information about an Erlang book to this mailing list is pretty good at that) - distribution (downloading a PDF covers that) - reviewing. Not post-publication reviews (though it would be good to have book reviews at www.erlang.org), but pre-publication ones: is this worth publishing? - editing. This includes idiom, grammar, spelling, punctuation, help with layout and diagrams, spotting omissions and duplications &c - negotiation to use copyright material (like the cover of my Prolog book). There can be community support for editing, so well edited free books are not impossible. But good editing is not free. *Someone* has to pay. From ivan@REDACTED Thu Mar 5 23:03:07 2015 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 5 Mar 2015 22:03:07 +0000 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: Good editing is rare in the traditional publishing world these days (imho). Certainly in computing. Caveat author if you rely on the publishing company to check the text/code/diagrams. Ivan -- festina lente > On 5 Mar 2015, at 21:37, Richard A. O'Keefe wrote: > > Traditional publishing offers a number of things > - advertising (sending information about an Erlang book to this mailing > list is pretty good at that) > - distribution (downloading a PDF covers that) > - reviewing. Not post-publication reviews (though it would be good to > have book reviews at www.erlang.org), but pre-publication ones: is > this worth publishing? > - editing. This includes idiom, grammar, spelling, punctuation, help > with layout and diagrams, spotting omissions and duplications &c > - negotiation to use copyright material (like the cover of my Prolog book). > > There can be community support for editing, so well edited free books are > not impossible. But good editing is not free. *Someone* has to pay. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Fri Mar 6 00:55:35 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 6 Mar 2015 12:55:35 +1300 Subject: [erlang-questions] Design pattern: single responsibility Message-ID: <3F0BD59B-C91E-476C-B4E0-D776C064A66B@cs.otago.ac.nz> We've had a thread about the use or otherwise of design patterns in Erlang. I've also had some mail that had me thinking about this. One idea which already has a name is "Single Responsibility". The Wikipedia article http://en.wikipedia.org/wiki/Single_responsibility_principle says it's about classes, but really it's nothing but cohesiveness by another name. In the context of Erlang, the idea is that each process should do one job. Advantages: Suppose a process has two jobs, A and B. And something about working on A makes it crash. Now nobody is doing job B. If we have two processes, they can execute on different cores. Disadvantages: If jobs A and B are coupled somehow, there will have to be communication between the processes working on them that there wouldn't be in a single process. Example: Separating logging from working. From jesper.louis.andersen@REDACTED Fri Mar 6 01:53:29 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 6 Mar 2015 01:53:29 +0100 Subject: [erlang-questions] Erlang - Java symmetric encryption In-Reply-To: <20150305184542.GA18321@earendil> References: <20150305184542.GA18321@earendil> Message-ID: On Thu, Mar 5, 2015 at 7:45 PM, Antonis Kouzoupis wrote: > What I want is to produce the same key both in mobile (java) and in server > (erlang), > Supposedly that the salt is the same. I use the erlang-pbkdf2 [0] module > to generate > the key in server and bouncy castle in java. Also I use AES in CTR mode in > both > sides to encrypt/decrypt, again the IV is known to both sides. So far the > decrypted ciphertext on server is not the same as the cleartext on mobile. > Can you give me any hint on how to correctly produce the same key (password > based) both in Erland and in Java? > I'm not really sure what your goal is cryptographically in this scheme. Clearly, one of the steps doesn't agree and this is why it fails, but what are you trying to achieve in the first place? Having a "naked" symmetric key with no way to replace it per session will make you quite susceptible to a global passive adversary since the scheme has no forward secrecy. Alternatively, look for a SRP implementation since it has provable zero-information loss once the key is initially set up on the server. But this depends on what your goals are. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Fri Mar 6 08:11:43 2015 From: eriksoe@REDACTED (=?UTF-8?Q?Erik_S=C3=B8e_S=C3=B8rensen?=) Date: Fri, 6 Mar 2015 08:11:43 +0100 Subject: [erlang-questions] inet setoptions after receive data In-Reply-To: References: <8E7DBA0859BD483F81AEF4A69653BFDB@gruchalski.com> Message-ID: Switching between packet formats *is* possible (we do it sometimes) *but* you should be aware of interactions with the 'active' socket option. That is, - don't use active=true when doing this. Race conditions! - active=once can be used, but should be off at the point where you change packetization. - Finally, for good measure, don't change 'packet' and 'active' in the same setopts call. /Erik Den 04/03/2015 16.45 skrev "Pedro Marques da Silva" : > Hi, > > I have looked before I post the question and is not clear why this will > happen. > > Maybe is not possible to switch from {packet,0} to {packet,4} after > receiving data on a socket! > > Best > > pms > > > > > -- > Pedro Marques da Silva > --------------------------------------------------- > E-mail Pessoal : posilva@REDACTED > --------------------------------------------------- > > 2015-03-04 11:25 GMT+00:00 Rad Gruchalski : > >> Hi Pedro, >> >> You should have a look at inet:setopts >> http://www.erlang.org/doc/man/inet.html#setopts-2 >> >> Kind regards, >> Radek Gruchalski >> radek@REDACTED >> de.linkedin.com/in/radgruchalski/ >> >> >> *Confidentiality:*This communication is intended for the above-named >> person and may be confidential and/or legally privileged. >> If it has come to you in error you must take no action based on it, nor >> must you copy or show it to anyone; please delete/destroy and inform the >> sender immediately. >> >> On Wednesday, 4 March 2015 at 01:48, Pedro Marques da Silva wrote: >> >> Hi Erlangers, >> >> I am doing a server to serve a flash application. When a flash client >> establish a connection(tcp socket) it sends a policy request (xml format >> message) and the server must reply with a policy file (xml file). After >> this exchange the client can connect to the socket as a regular connection. >> >> >> When I accept the connection the socket have a {packet,0} option set and >> checks if is a policy request and sends the policy file back. After this I >> change the option to {packet,4} but I do not receive anymore data. If I >> stay with {packet,0} I will receive the binary data sent by the client >> >> >> Any one knows about any problem with changing socket options after >> receive some data? >> >> thanks >> -- >> Pedro Marques da Silva >> --------------------------------------------------- >> E-mail Pessoal : posilva@REDACTED >> --------------------------------------------------- >> _______________________________________________ >> 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 manuel@REDACTED Fri Mar 6 08:18:59 2015 From: manuel@REDACTED (=?UTF-8?Q?Manuel_Dur=C3=A1n_Aguete?=) Date: Fri, 6 Mar 2015 08:18:59 +0100 Subject: [erlang-questions] Erlang - Java symmetric encryption In-Reply-To: <20150305184542.GA18321@earendil> References: <20150305184542.GA18321@earendil> Message-ID: Hello, You can try something like http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange to exchange keys. Regards. 2015-03-05 19:45 GMT+01:00 Antonis Kouzoupis : > Hi, > > I'm trying to build a system where mobile devices (Android) will > communicate > each other encrypted TCP messages and the symmetric key distribution will > be handled by a server in Erlang. As an Erlang *newbie*, I've been > confused with > the key derivation and encryption/decryption. > > What I want is to produce the same key both in mobile (java) and in server > (erlang), > Supposedly that the salt is the same. I use the erlang-pbkdf2 [0] module > to generate > the key in server and bouncy castle in java. Also I use AES in CTR mode in > both > sides to encrypt/decrypt, again the IV is known to both sides. So far the > decrypted ciphertext on server is not the same as the cleartext on mobile. > Can you give me any hint on how to correctly produce the same key (password > based) both in Erland and in Java? > > [0] https://github.com/whitelynx/erlang-pbkdf2 > > Thank you for your time, > -- > ??????? ????????? > Antonis Kouzoupis > > _______________________________________________ > 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 Fri Mar 6 10:13:00 2015 From: davidnwelton@REDACTED (David Welton) Date: Fri, 6 Mar 2015 10:13:00 +0100 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: > - reviewing. Not post-publication reviews (though it would be good to > have book reviews at www.erlang.org), but pre-publication ones: is > this worth publishing? I like to see even self-published books on Amazon.com for this reason - it's nice to see what other people think of something. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From zkessin@REDACTED Fri Mar 6 13:00:44 2015 From: zkessin@REDACTED (Zachary Kessin) Date: Fri, 06 Mar 2015 14:00:44 +0200 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: <54F996EC.5080709@gmail.com> Good point, I will add a sample chapter to the web page (though it may wait until Sunday) --Zach On 3/5/15 1:50 PM, Roger Lipscombe wrote: >> If Zach wishes to charge money for his book, that's his prerogative. >> He's written before and is likely aware of the consequences (Will >> readers expense it at work, pirate it at home, borrow it from a library? >> Does pricing change the perception people have from the book in terms of >> quality?) and able to choose what he's comfortable with. > Absolutely agree with this. It is totally Zach's prerogative. Doesn't > make me stop wishing that there was a sample chapter available for > free, though. $39 seems like a lot to plunk down sight unseen. For > this reason alone, I'll be holding back. > > Contrast this with the fact that I just this morning bought "Your Code > As a Crime Scene" from Pragpub based on reading a couple of sample > pages. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.rosa@REDACTED Fri Mar 6 10:56:47 2015 From: andrea.rosa@REDACTED (Rosa, Andrea (HP Cloud Services)) Date: Fri, 6 Mar 2015 09:56:47 +0000 Subject: [erlang-questions] Reload ssl configuration and automatic renegotiation Message-ID: <5F389C517756284F80239F55BCA5DDDD6AD4D871@G4W3298.americas.hpqcorp.net> Hi all I am newcomer to eralng so bear with me. In a client server application my server uses TLS to accept requests, I need to change my server certificate quite often and in order to reload the new configuration at the moment I stop and start the ssl module. Doing that all my running connections get closed, I am wonder if there is a different way to reload the new certificate without breaking existing connections maybe renegotiating the parameters for them. Regards -- Andrea Rosa From tuncer.ayaz@REDACTED Fri Mar 6 14:44:28 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 6 Mar 2015 14:44:28 +0100 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: On Thu, Mar 5, 2015 at 10:37 PM, Richard A. O'Keefe wrote: > Traditional publishing offers a number of things [...] > - editing. This includes idiom, grammar, spelling, punctuation, help > with layout and diagrams, spotting omissions and duplications &c > - negotiation to use copyright material (like the cover of my Prolog book). > > There can be community support for editing, so well edited free > books are not impossible. But good editing is not free. *Someone* > has to pay. What publishers have good editing these days? Maybe I didn't notice such faults in the past, but in books and magazines distributed by major publishing houses in the last decade (or longer) I've noticed an increase in easy to catch grammar and typo faults that went to the printing presses unchanged. I can and do auto-correct them while reading, but it slows down reading the same way error correction adds latency. Was this less of an issue in <=1999? If the quality has declined, can this be attributed to the Internet and maybe cuts in editing departments? @Ivan: It's not just computing press that seems affected by the decrease in editing quality. From huaqiao.long@REDACTED Fri Mar 6 14:18:21 2015 From: huaqiao.long@REDACTED (=?utf-8?B?SHVhcWlhbyBMb25n?=) Date: Fri, 6 Mar 2015 21:18:21 +0800 Subject: [erlang-questions] Unknown message in httpc_manager:handle_info Message-ID: Sometimes getting this error report with httpc?: =ERROR REPORT==== 6-Mar-2015::18:26:56 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48384>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:06 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48409>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:06 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48433>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:11 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48470>,ok}? I haven't been able to figure out why it happens or who sends the erroneous message. Has anyone seen this before or know what may be causing it?? Maybe is httpc_manager have bug? Best, Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.meadows.jonsson@REDACTED Fri Mar 6 16:29:48 2015 From: eric.meadows.jonsson@REDACTED (=?UTF-8?Q?Eric_Meadows=2DJ=C3=B6nsson?=) Date: Fri, 6 Mar 2015 16:29:48 +0100 Subject: [erlang-questions] Unknown message in httpc_manager:handle_info In-Reply-To: References: Message-ID: I reported this last year with no reponses unfortunately. http://erlang.org/pipermail/erlang-questions/2014-November/081703.html On Fri, Mar 6, 2015 at 2:18 PM, Huaqiao Long wrote: > Sometimes getting this error report with httpc?: > > =ERROR REPORT==== 6-Mar-2015::18:26:56 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48384>,ok} > > > > =ERROR REPORT==== 6-Mar-2015::18:27:06 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48409>,ok} > > > > =ERROR REPORT==== 6-Mar-2015::18:27:06 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48433>,ok} > > > > =ERROR REPORT==== 6-Mar-2015::18:27:11 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48470>,ok}? > > > I haven't been able to figure out why it happens or who sends the > erroneous message. > Has anyone seen this before or know what may be causing it?? > Maybe is httpc_manager have bug? > > Best, > Thanks > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Eric Meadows-J?nsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From felixgallo@REDACTED Fri Mar 6 17:26:16 2015 From: felixgallo@REDACTED (Felix Gallo) Date: Fri, 6 Mar 2015 08:26:16 -0800 Subject: [erlang-questions] Unknown message in httpc_manager:handle_info In-Reply-To: References: Message-ID: httpc has at least one race condition under load. I would strongly recommend using a different library that has active maintainers, such as hackney (https://github.com/benoitc/hackney). On Fri, Mar 6, 2015 at 7:29 AM, Eric Meadows-J?nsson < eric.meadows.jonsson@REDACTED> wrote: > I reported this last year with no reponses unfortunately. > > http://erlang.org/pipermail/erlang-questions/2014-November/081703.html > > On Fri, Mar 6, 2015 at 2:18 PM, Huaqiao Long > wrote: > >> Sometimes getting this error report with httpc?: >> >> =ERROR REPORT==== 6-Mar-2015::18:26:56 === >> >> Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48384>,ok} >> >> >> >> =ERROR REPORT==== 6-Mar-2015::18:27:06 === >> >> Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48409>,ok} >> >> >> >> =ERROR REPORT==== 6-Mar-2015::18:27:06 === >> >> Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48433>,ok} >> >> >> >> =ERROR REPORT==== 6-Mar-2015::18:27:11 === >> >> Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48470>,ok}? >> >> >> I haven't been able to figure out why it happens or who sends the >> erroneous message. >> Has anyone seen this before or know what may be causing it?? >> Maybe is httpc_manager have bug? >> >> Best, >> Thanks >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Eric Meadows-J?nsson > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists@REDACTED Fri Mar 6 17:51:42 2015 From: lists@REDACTED (Camille Troillard) Date: Fri, 6 Mar 2015 17:51:42 +0100 Subject: [erlang-questions] Line wrapping issue when attaching to running node In-Reply-To: References: <83111B73-54CC-4118-871A-03C0E4C1D923@tuli.pe> Message-ID: <8E37514B-B7FE-4FDA-84F3-BCF482FCFE18@tuli.pe> Hello Lukas, I tried Erlang/OTP 17.4.1 (erts-6.3.1) and the problem is still present. Could it be that to_erl also needs to be fixed? I can see that the executable I am interacting with is to_erl, but OTP-12275 mentions run_erl. Best, Camille > On Dec 27, 2014, at 18:53, Lukas Larsson wrote: > > I think this might be a bug that was introduced in 17.0, that has been fixed in 17.4. See OTP-12275 in the erts release notes. > > On Sat, Dec 27, 2014 at 5:12 PM, Karolis Petrauskas > wrote: > Hi, > > I have the same problem and I have no solution for it. I think it is > related to the terminal specified when starting the node (not when > attaching to it). > > The only workaround I found was to type commands in a text editor and > copy/paste them to the terminal. > > Karolis > > On Tue, Dec 23, 2014 at 5:00 PM, Camille Troillard > wrote: > > Hello, > > > > We are experiencing an annoying problem in integration or production environment that deals with incorrect line wrapping when connecting to a remote shell. > > > > Erlang version: > > Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false] > > > > Installed on FreeBSD using the `erlang-17.3_3,3` package. > > > > > > We generate a release using rebar. When we want to interact with it, we attach to the system like so (assuming the release is named ?abc?) : > > > > $ ./rel/abc/bin/abc attach > > > > (abc@REDACTED )1> > > > > > > In this situation, whenever you write something that exceeds the width of the terminal (typically 80 columns), the line wraps onto a second line, which is OK. But if you have an open parenthesis on the first line, that is closed on the second line, then the output becomes garbled, text overwritten and it is no longer possible to sanely use the shell. > > > > This is an example of expected output: > > > > (abc@REDACTED )1> this_is_an_example_of_a_long_module_name:call_this_function([1 > > , 2, 3, 4], another_arg). > > > > And the actual output (the cursor is on the first line at column 2): > > > > .abc@REDACTED, another_arg)an_example_of_a_long_module_name:call_this_function([1 > > , 2, 3, 4] > > > > > > Text garbling occurs as soon as I hit the first ?]?. It also occurs on ?)?. > > > > It does not happen when typing into an erlang shell that was launched using `erl` directly. > > > > It seems to happen to_erl. The same erratic behaviour is seen when attach to a release running on FreeBSD or OS X. It does not matter whether the console is running locally or via SSH. Also, it does not seem to matter wether the TERM variable is set to ansi, vt100, xterm or xterm-256color. > > > > > > I would like to know if someone noticed this problem, and how to fix it. > > > > Thanks ! > > Camille -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyarly@REDACTED Fri Mar 6 18:57:40 2015 From: nyarly@REDACTED (Judson Lester) Date: Fri, 06 Mar 2015 17:57:40 +0000 Subject: [erlang-questions] Design pattern: single responsibility Message-ID: I'll admit, I didn't have whole-application patterns in mind when I brought it up, but it definitely seems like an area in Erlang worthy of discussion. Which is what design patterns are for: not just "it depends" but "on what" and "between these alternatives." It also seems like Single Responsibility might apply to modules, even within a process. As a novice in Erlang, I think I was getting (read: misunderstanding) the message that module = process, partly from the pattern of exposing interfaces in the same module that defines a gen_server behavior (a practice now enshrined in an Elixir macro). I've been finding good outcomes from breaking up modules the same way e.g. you might break up a function into smaller ones. I'm sure I'm not the only one, right? Judson On Thu, Mar 5, 2015 at 3:55 PM Richard A. O'Keefe wrote: > We've had a thread about the use or otherwise of design patterns in Erlang. > I've also had some mail that had me thinking about this. > > One idea which already has a name is "Single Responsibility". > The Wikipedia article http://en.wikipedia.org/wiki/Single_responsibility_ > principle > says it's about classes, but really it's nothing but cohesiveness > by another name. > > In the context of Erlang, > the idea is that each process should do one job. > Advantages: > > Suppose a process has two jobs, A and B. > And something about working on A makes it crash. > Now nobody is doing job B. > > If we have two processes, they can execute on > different cores. > > Disadvantages: > > If jobs A and B are coupled somehow, there will have > to be communication between the processes working on > them that there wouldn't be in a single process. > > Example: > > Separating logging from working. > > _______________________________________________ > 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 Fri Mar 6 21:29:46 2015 From: pablo.platt@REDACTED (pablo platt) Date: Fri, 6 Mar 2015 22:29:46 +0200 Subject: [erlang-questions] GObject bindings Message-ID: Hi, Are there Erlang bindings for GObject (Glib, GStreamer...)? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgu@REDACTED Sat Mar 7 01:31:13 2015 From: zgu@REDACTED (Zhongxian Gu) Date: Sat, 7 Mar 2015 00:31:13 +0000 Subject: [erlang-questions] gen_tcp:recv/2 does not work with ssl socket? Message-ID: Hi, With a ssl_socket, I tried to get a fixed number of bytes through en_tcp:recv(SslSocket, 1) but failed. The stack trace pointed to: ** {function_clause,[{gen_tcp,recv, [{sslsocket,{gen_tcp,#Port<0.1418>},<0.534.0>}, 1], [{file,"gen_tcp.erl"},{line,280}]}, Does that means gen_tcp:recv function does not work with Ssl socket? Thanks, Zhongxian -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaqiao.long@REDACTED Sat Mar 7 03:20:38 2015 From: huaqiao.long@REDACTED (=?utf-8?B?SHVhcWlhbyBMb25n?=) Date: Sat, 7 Mar 2015 10:20:38 +0800 Subject: [erlang-questions] =?utf-8?b?5Zue5aSN77yaICBVbmtub3duIG1lc3NhZ2Ug?= =?utf-8?q?in_httpc=5Fmanager=3Ahandle=5Finfo?= In-Reply-To: References: Message-ID: Yes, I've seen your report, I think this is a bug.? ------------------ ???? ------------------ ???: "Eric Meadows-J?nsson";; ????: 2015?3?6?(???) ??11:29 ???: "Huaqiao Long"; ??: "erlang-questions"; ??: Re: [erlang-questions] Unknown message in httpc_manager:handle_info I reported this last year with no reponses unfortunately. http://erlang.org/pipermail/erlang-questions/2014-November/081703.html On Fri, Mar 6, 2015 at 2:18 PM, Huaqiao Long wrote: Sometimes getting this error report with httpc?: =ERROR REPORT==== 6-Mar-2015::18:26:56 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48384>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:06 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48409>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:06 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48433>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:11 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48470>,ok}? I haven't been able to figure out why it happens or who sends the erroneous message. Has anyone seen this before or know what may be causing it?? Maybe is httpc_manager have bug? Best, Thanks _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- Eric Meadows-J?nsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.widgren@REDACTED Sat Mar 7 09:14:15 2015 From: daniel.widgren@REDACTED (Daniel Hallin Widgren) Date: Sat, 7 Mar 2015 09:14:15 +0100 Subject: [erlang-questions] gen_tcp:recv/2 does not work with ssl socket? In-Reply-To: References: Message-ID: I think socket needs to be in the format that you get from gen_tcp:accept. Den 7 mar 2015 08:16 skrev "Zhongxian Gu" : > Hi, > > With a ssl_socket, I tried to get a fixed number of bytes through > en_tcp:recv(SslSocket, 1) but failed. > > The stack trace pointed to: > > ** {function_clause,[{gen_tcp,recv, > > [{sslsocket,{gen_tcp,#Port<0.1418>},<0.534.0>}, > 1], > [{file,"gen_tcp.erl"},{line,280}]}, > > Does that means gen_tcp:recv function does not work with Ssl socket? > > Thanks, > > Zhongxian > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.widgren@REDACTED Sat Mar 7 09:28:11 2015 From: daniel.widgren@REDACTED (Daniel Hallin Widgren) Date: Sat, 7 Mar 2015 09:28:11 +0100 Subject: [erlang-questions] gen_tcp:recv/2 does not work with ssl socket? In-Reply-To: References: Message-ID: Have you tried ssl:recv/2? Den 7 mar 2015 09:14 skrev "Daniel Hallin Widgren" : > I think socket needs to be in the format that you get from gen_tcp:accept. > Den 7 mar 2015 08:16 skrev "Zhongxian Gu" : > >> Hi, >> >> With a ssl_socket, I tried to get a fixed number of bytes through >> en_tcp:recv(SslSocket, 1) but failed. >> >> The stack trace pointed to: >> >> ** {function_clause,[{gen_tcp,recv, >> >> [{sslsocket,{gen_tcp,#Port<0.1418>},<0.534.0>}, >> 1], >> [{file,"gen_tcp.erl"},{line,280}]}, >> >> Does that means gen_tcp:recv function does not work with Ssl socket? >> >> Thanks, >> >> Zhongxian >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.otp@REDACTED Sat Mar 7 12:36:26 2015 From: anders.otp@REDACTED (Anders Svensson) Date: Sat, 7 Mar 2015 12:36:26 +0100 Subject: [erlang-questions] Design patterns? In-Reply-To: <8CDA8215-6250-449A-9D7B-D4FC0F073415@feuerlabs.com> References: <8CDA8215-6250-449A-9D7B-D4FC0F073415@feuerlabs.com> Message-ID: Proponent is the right word, and Ulf correctly identifies the reason my code looks as it does: trace. Erlang has excellent trace facilities, cryptic match specs and all, and being able to see what the code is doing by enabling some judicious trace is truly golden. The bigger the system, the more valuable it becomes. The only thing I miss (aside from instant recall of the match spec grammar that is) is the possibility of having multiple tracer processes: being able to write trace-based test/debug tools that don't interfere with each other would be a huge plus. Communication is also important of course, but the smaller the function clause, the less it can do wrong, the easier it is to pinpoint problems with trace. (And even without trace I'd argue.) Readability is subjective in any case. I'd label some of my own overly concise variable names a fail on that point, but I have far more difficulty reading code that expands horizontally than code that expands vertically. There's no debating that nested case and large funs contribute to code that can be difficult to trace however. Anders On Wed, Mar 4, 2015 at 11:49 AM, Ulf Wiger wrote: > > On 02 Mar 2015, at 20:20, Judson Lester wrote: > > And an open question (for me): when to use case/if versus function heads? > Roughly, I've been using cases to reformat the returns of a function call, > but the decision trips me up every time. > > > There is a consideration worth noting that can affect this decision: > > While you can?t trace on a given case expression, you *can* trace a function > call. > > In general, I very much agree with Richard O?Keefe: you should choose > whatever best communicates your intent. > > However, and perhaps Anders Svensson (now on the OTP team) is one of the > most extreme proponents of this view, breaking out things like local funs > into separate functions, makes it much easier to debug. This is especially > true in live real-time systems, where tracing is one of the few ways you > *can* debug (hopefully) without making a mess of things. > > Now, Erlang does allow you to selectively trace on anonymous funs, in part > since it translates them into actual functions using a consistent naming > scheme, but only the nerdiest of Erlang programmers have actually memorized > this scheme. So if the code looks like this (example from OTP?s ?diameter? > application): > > merge_service(Opts, Svc) -> > lists:foldl(fun ms/2, Svc, Opts). > > ms({applications, As}, #diameter_service{applications = Apps} = S) > when is_list(As) -> > > ? > > insert_local_peer(SApps, T, LDict) -> > lists:foldl(fun(A,D) -> ilp(A, T, D) end, LDict, SApps). > > ilp({Id, Alias}, {TC, SA}, LDict) -> > ? > > - then you have no problems tracing the ?inner loop? function of e.g. a > fold. > > (Note that in the second example, Anders uses an anonymous fun to include > part of the environment.) > > From an aesthetic (i.e. communication) standpoint, I find it slightly > unfortunate, but OTOH, when it?s consistently and competently done, I will > agree that you reasonably quickly get used to ?decoding? the style. > > For those who want to judge whether it?s a technique they want to adopt, I > recommend reading the diameter sources, where it *is* pretty consistently > applied. > > BR, > Ulf > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From kouzan@REDACTED Sat Mar 7 13:57:51 2015 From: kouzan@REDACTED (Antonis Kouzoupis) Date: Sat, 7 Mar 2015 13:57:51 +0100 Subject: [erlang-questions] Erlang - Java symmetric encryption In-Reply-To: References: <20150305184542.GA18321@earendil> Message-ID: <20150307125748.GA30243@earendil> Hi, Thank you all for your responses. Luckily the problem was more easy, as an erlang *newbie* I wasn't pattern matching correctly against some value resulting in different keys at the two entities (Erlang - Java). For the record, in the system I'm building two mobile devices will communicate encrypted with a session key, which they both hold, issued by the erlang server. (Needham-Schroeder protocol) [0] The point is to avoid public-key cryptography which is more "expensive" and to keep the environment of the communicating counterparts closed to foreign ones, so I don't want to use TLS. [0] https://en.wikipedia.org/wiki/Needham%E2%80%93Schroeder_protocol BR -- ??????? ????????? Antonis Kouzoupis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From radek@REDACTED Sat Mar 7 18:42:47 2015 From: radek@REDACTED (Rad Gruchalski) Date: Sat, 7 Mar 2015 18:42:47 +0100 Subject: [erlang-questions] Reload ssl configuration and automatic renegotiation In-Reply-To: <5F389C517756284F80239F55BCA5DDDD6AD4D871@G4W3298.americas.hpqcorp.net> References: <5F389C517756284F80239F55BCA5DDDD6AD4D871@G4W3298.americas.hpqcorp.net> Message-ID: <09B284706A1043A6ABA6B1DE21D89810@gruchalski.com> What is the software you use to accept connections? Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Friday, 6 March 2015 at 10:56, Rosa, Andrea (HP Cloud Services) wrote: > Hi all > > I am newcomer to eralng so bear with me. > > In a client server application my server uses TLS to accept requests, I need to change my server certificate quite often and in order to reload the new configuration at the moment I stop and start the ssl module. > Doing that all my running connections get closed, I am wonder if there is a different way to reload the new certificate without breaking existing connections maybe renegotiating the parameters for them. > > Regards > -- > Andrea Rosa > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Sat Mar 7 19:21:22 2015 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Sat, 7 Mar 2015 19:21:22 +0100 Subject: [erlang-questions] Design patterns? In-Reply-To: References: <8CDA8215-6250-449A-9D7B-D4FC0F073415@feuerlabs.com> Message-ID: On Sat, Mar 7, 2015 at 12:36 PM, Anders Svensson wrote: > The only thing I miss (aside from instant recall > of the match spec grammar that is) is the possibility of having > multiple tracer processes: being able to write trace-based test/debug > tools that don't interfere with each other would be a huge plus. > That gets a +99 from me too. I looked into it for some time ago, but IIRC it went complicated very fast. It was also not obvious how to make a nice API for it. best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Sun Mar 8 08:21:46 2015 From: davidnwelton@REDACTED (David Welton) Date: Sun, 8 Mar 2015 08:21:46 +0100 Subject: [erlang-questions] Design patterns? In-Reply-To: <0F62A367-4151-4815-9500-0C9F5B0DB2F4@basho.com> References: <54f5712a.d295b40a.2a9a.6551@mx.google.com> <0F62A367-4151-4815-9500-0C9F5B0DB2F4@basho.com> Message-ID: > So Erlanger?s don?t tend to talk about ?design patterns? so much as ?use > OPT? There are things that OTP either leaves out or doesn't provide much guidance with: * Isolating 'unreliable' resources: https://github.com/jlouis/fuse (he links to other similar projects) * Resource pools. * Going beyond "let it crash". http://jlouisramblings.blogspot.it/2010/11/on-erlang-state-and-crashes.html - some mention of UI with regards to that would make for another great article. I think those are all 'design patterns' worthy of discussion; they mostly have code available to discuss as well. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From edwardlblake@REDACTED Sun Mar 8 05:40:05 2015 From: edwardlblake@REDACTED (Edward Blake) Date: Sat, 7 Mar 2015 23:40:05 -0500 Subject: [erlang-questions] Reusing patterns and guard sequences Message-ID: Hello all, Recently I've went and began implementing a concept preprocessor that extends Erlang's pattern matching and guard syntax with constructs to make bundles of patterns and guard sequences reusable, one of which resembles a form of user-defined guard. A few quick examples: -------------------------- %% example1.erl %% -module(example1). -export([ test/0 ]). -auto_include_udg([ \\non_empty_message/3, is_uep_displayable_uuid/1 ]). -record(message, { flags = 0, data = <<>>, uuid = <<>>}). test() -> receive Message \\ non_empty_message(UUID, MsgFlags, MsgLine) when MsgFlags /= 0, is_uep_displayable_uuid(UUID) orelse UUID =:= <<>> -> io:format("From UUID: ~s~n", [UUID]), io:format("Message: ~s", [MsgLine]) after 1000 -> ok end. -------------------------- %% example2.erl %% -module(example2). -export([ test/1 ]). -auto_include_udg([ \\integer_in_second_place/1 ]). test(Compound \\ integer_in_second_place(Val)) -> Val. -------------------------- For these examples the definitions for the pattern templates and guards are: -------------------------- %% non_empty_message.erg %% -user_defined_guard(non_empty_message, [ \\non_empty_message/3 ]). (#message{ flags = MsgFlags, data = MsgLine, uuid = UUID }) \\ non_empty_message(UUID, MsgFlags, MsgLine) when is_binary(MsgLine), MsgLine =/= <<>>. -------------------------- %% displayable_uuid.erg %% -user_defined_guard(displayable_uuid, [ is_uep_displayable_uuid/6, is_uep_displayable_uuid/1, \\displayable_uuid/5, \\displayable_uuid/0 ]). (UUID \\ displayable_uuid(_,_,_,_,_)) \\ displayable_uuid(). (<>) \\ displayable_uuid( UUID_Part_1, UUID_Part_2, UUID_Part_3, UUID_Part_4, UUID_Part_5). is_uep_displayable_uuid(UUID \\ displayable_uuid()). is_uep_displayable_uuid( UUID \\ displayable_uuid(UUID_Part_1, UUID_Part_2, UUID_Part_3, UUID_Part_4, UUID_Part_5), UUID_Part_1,UUID_Part_2,UUID_Part_3,UUID_Part_4,UUID_Part_5). -------------------------- %% integer_in_second_place.erg %% -user_defined_guard(integer_in_second_place, [ \\integer_in_second_place/1 ]). ([_,Value|_]) \\ integer_in_second_place(Value) := is_integer(Value); ({_,Value}) \\ integer_in_second_place(Value) := is_integer(Value); ({_,Value,_}) \\ integer_in_second_place(Value) when is_integer(Value). -------------------------- A more thorough overview and description, as well as the preprocessor source as it currently exists, can be found at the repository at: https://github.com/elblake/udg The beginnings of a test suite is present which does some tests over a series of source file scenarios, the loading of definition source files, and modules requiring user input, one of which tests all files in a directory recursively that preprocessed files are identical token-wise with the original file, intended to see if the preprocessor splits and recombines alternatives within function heads, cases, funs, receives, trys and ifs correctly as well an indication if it could handle Erlang code in a real world setting. I've passed that test over my erlang installation's lib directory and they all pass. However the preprocessor does skip over definitions that contain ? in some places of the function head since it doesn't implement macro expansion. And there is also another test early in design which randomly generates arbitrary Erlang (albeit of a very small subset) source code with randomly selected patterns and guards. For the convenience of testing it out, an erlc_udg module takes as command line input an erl file to preprocess it before compiling it with compile:file. I also apologize in advance for using the term "user-defined guard" for the concept construct as that was what I was using as a working name during implementation, I could have used another term but I couldn't come up with one as of yet. The preprocessor is a very early implementation and not complete in many cases, some types of expressions are not parsed for the .erg definitions for example, erroneous conditions in input source code simply causes run-time errors without any presentation, and some scenarios with binaries are a work in progress. The (:=) operator was chosen to delimit the tail guard expression simply because I wanted an erl_scan available operator that would go before the disjunction operator to maintain a similarity to full head disjunctions of functions, so having semicolons directly after 'when' wouldn't do, and using (->) which normally hints to a sequence of general purpose expressions for this purpose would be confusing. Input is welcome. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.rosa@REDACTED Mon Mar 9 10:54:42 2015 From: andrea.rosa@REDACTED (Rosa, Andrea (HP Cloud Services)) Date: Mon, 9 Mar 2015 09:54:42 +0000 Subject: [erlang-questions] Reload ssl configuration and automatic renegotiation In-Reply-To: <09B284706A1043A6ABA6B1DE21D89810@gruchalski.com> References: <5F389C517756284F80239F55BCA5DDDD6AD4D871@G4W3298.americas.hpqcorp.net> <09B284706A1043A6ABA6B1DE21D89810@gruchalski.com> Message-ID: <5F389C517756284F80239F55BCA5DDDD6AD4E031@G4W3298.americas.hpqcorp.net> Hi The software is Rabbitmq Version 3.2.4. I talked with Rabbitmq guys and it seems there isn?t a way to do it from the application, the only thing we can do is to call erlang command inside the rabbitmq applications using a rabbitmq command, something like ?RMQCommand eval ?erlang instructions?? Thanks -- Andrea Rosa From: Rad Gruchalski [mailto:radek@REDACTED] Sent: 07 March 2015 17:43 To: Rosa, Andrea (HP Cloud Services) Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Reload ssl configuration and automatic renegotiation What is the software you use to accept connections? Kind regards, Radek Gruchalski radek@REDACTED de.linkedin.com/in/radgruchalski/ Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Friday, 6 March 2015 at 10:56, Rosa, Andrea (HP Cloud Services) wrote: Hi all I am newcomer to eralng so bear with me. In a client server application my server uses TLS to accept requests, I need to change my server certificate quite often and in order to reload the new configuration at the moment I stop and start the ssl module. Doing that all my running connections get closed, I am wonder if there is a different way to reload the new certificate without breaking existing connections maybe renegotiating the parameters for them. Regards -- Andrea Rosa _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Mon Mar 9 12:04:59 2015 From: imantc@REDACTED (Imants Cekusins) Date: Mon, 9 Mar 2015 12:04:59 +0100 Subject: [erlang-questions] Reload ssl configuration and automatic renegotiation In-Reply-To: <5F389C517756284F80239F55BCA5DDDD6AD4E031@G4W3298.americas.hpqcorp.net> References: <5F389C517756284F80239F55BCA5DDDD6AD4D871@G4W3298.americas.hpqcorp.net> <09B284706A1043A6ABA6B1DE21D89810@gruchalski.com> <5F389C517756284F80239F55BCA5DDDD6AD4E031@G4W3298.americas.hpqcorp.net> Message-ID: these commands might work: ssl:setopts(Socket, [{cacertfile, path()},{keyfile, path()}, {password, string()}]). ssl:renegotiate(Socket). http://www.erlang.org/doc/man/ssl.html#setopts-2 http://www.erlang.org/doc/man/ssl.html#renegotiate-1 , no? From andrea.rosa@REDACTED Mon Mar 9 13:00:37 2015 From: andrea.rosa@REDACTED (Rosa, Andrea (HP Cloud Services)) Date: Mon, 9 Mar 2015 12:00:37 +0000 Subject: [erlang-questions] Reload ssl configuration and automatic renegotiation In-Reply-To: References: <5F389C517756284F80239F55BCA5DDDD6AD4D871@G4W3298.americas.hpqcorp.net> <09B284706A1043A6ABA6B1DE21D89810@gruchalski.com> <5F389C517756284F80239F55BCA5DDDD6AD4E031@G4W3298.americas.hpqcorp.net> Message-ID: <5F389C517756284F80239F55BCA5DDDD6AD500F1@G4W3298.americas.hpqcorp.net> Hi Thank you very much for your reply, >From: Imants Cekusins [mailto:imantc@REDACTED] >Sent: 09 March 2015 11:05 > >these commands might work: > >ssl:setopts(Socket, [{cacertfile, path()},{keyfile, path()}, {password, string()}]). > >ssl:renegotiate(Socket). Are you suggesting to call the renegotiate on each open socket? If so I think it is a good suggestion but not sure it is implemented in my application (rabbitmq) yet. Regards -- Andrea Rosa From imantc@REDACTED Mon Mar 9 13:40:49 2015 From: imantc@REDACTED (Imants Cekusins) Date: Mon, 9 Mar 2015 13:40:49 +0100 Subject: [erlang-questions] Reload ssl configuration and automatic renegotiation In-Reply-To: <5F389C517756284F80239F55BCA5DDDD6AD500F1@G4W3298.americas.hpqcorp.net> References: <5F389C517756284F80239F55BCA5DDDD6AD4D871@G4W3298.americas.hpqcorp.net> <09B284706A1043A6ABA6B1DE21D89810@gruchalski.com> <5F389C517756284F80239F55BCA5DDDD6AD4E031@G4W3298.americas.hpqcorp.net> <5F389C517756284F80239F55BCA5DDDD6AD500F1@G4W3298.americas.hpqcorp.net> Message-ID: > Are you suggesting to call the renegotiate on each open socket? yes, I would try this. Hopefully someone corrects me if this won't work - to save you time. > not sure it is implemented in my application (rabbitmq) yet. well if this works with Rabbit: RMQCommand eval 'your_module_A:run()' you could write up a module your_module_A and call it like this. Hopefully there is a way to retrieve sockets opened by Rabbit somehow. From roberto@REDACTED Mon Mar 9 16:11:01 2015 From: roberto@REDACTED (Roberto Ostinelli) Date: Mon, 9 Mar 2015 16:11:01 +0100 Subject: [erlang-questions] MNESIA ram-only Message-ID: Dear list, I am starting MNESIA in RAM only mode, with the option [1]: -mnesia schema_location ram. Every time I start a gen_server, I first ensure to add all the other nodes in the island like so: mnesia:change_config(extra_db_nodes, [node() | nodes()]). I then create the table I need: mnesia:create_table(cometa_online_devices, [ {type, set}, {ram_copies, [node() | nodes()]}, {attributes, record_info(fields, my_record)}, {index, [#my_record.pid]}, {storage_properties, [{ets, [{read_concurrency, true}]}]} ]) I do so mainly to avoid the hassle of creating a schema. As you can see I only use ram tables. My question here is: is this an appropriate use? What kind of problems may I get myself into by not using a disc schema? Thank you, r. [1] http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id76396 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawel@REDACTED Mon Mar 9 16:39:45 2015 From: pawel@REDACTED (Pawel Kraszewski) Date: Mon, 9 Mar 2015 16:39:45 +0100 Subject: [erlang-questions] Various EDoc questions Message-ID: Hello fellow Erlangers. * EDoc generates a documentation sections for types, functions, function details, et al. Each of the sections is sorted alphabetically. Is there a way to make EDoc retain in-source function order? I use erlang.mk with "docs" target to generate EDoc, and have already set some useful (for me) flags in EDOC_OPTS. * EDoc generates (X)HTML documents. Sole construction of EDoc implies possibility to implement plug-ins generating other formats. Are there any examples for other output formats? I?d be particularly interested in LaTeX and/or MarkDown formats. Generally I need printable documentation of the whole OTP application as a single document. * Is there an easy way to make EDoc output non-English? I mean other than editing EDoc-library source code itself? I guess this may be extension to the previous question? * If code references (for example via -spec(...).) standard OTP non-trivial type, for example public_key:der_encoded(), EDoc generates link pointing into darkness. Is there a way to prevent such invalid links, or (better) include documentation of type referenced? * And last but not least ? which documentation form is preferred (if not both at once), via -spec(...). or via %% @spec ..., as they seem totally redundant? I heavily use Dialyzer, if this information is relevant. Best regards. -- Pawe? Kraszewski From vances@REDACTED Mon Mar 9 20:24:29 2015 From: vances@REDACTED (Vance Shipley) Date: Tue, 10 Mar 2015 00:54:29 +0530 Subject: [erlang-questions] Various EDoc questions In-Reply-To: References: Message-ID: On Mon, Mar 9, 2015 at 9:09 PM, Pawel Kraszewski wrote: > Is there a way to make EDoc retain in-source function order? {sort_functions, boolean()} http://erlang.org/doc/man/edoc_layout.html -- -Vance From dangud@REDACTED Mon Mar 9 21:19:06 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Mon, 9 Mar 2015 21:19:06 +0100 Subject: [erlang-questions] MNESIA ram-only In-Reply-To: References: Message-ID: Sure, you do not need to specify schema_location ram since that is the default if no schema exists on disc. Just be sure that all nodes in cluster are in the nodes() list. /Dan On Mon, Mar 9, 2015 at 4:11 PM, Roberto Ostinelli wrote: > Dear list, > I am starting MNESIA in RAM only mode, with the option [1]: > > -mnesia schema_location ram. > > Every time I start a gen_server, I first ensure to add all the other nodes > in the island like so: > > mnesia:change_config(extra_db_nodes, [node() | nodes()]). > > I then create the table I need: > > mnesia:create_table(cometa_online_devices, [ > {type, set}, > {ram_copies, [node() | nodes()]}, > {attributes, record_info(fields, my_record)}, > {index, [#my_record.pid]}, > {storage_properties, [{ets, [{read_concurrency, true}]}]} > ]) > > I do so mainly to avoid the hassle of creating a schema. As you can see I > only use ram tables. > > My question here is: is this an appropriate use? What kind of problems may > I get myself into by not using a disc schema? > > Thank you, > r. > > > > [1] http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id76396 > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.ostinelli@REDACTED Mon Mar 9 21:28:20 2015 From: roberto.ostinelli@REDACTED (Roberto Ostinelli) Date: Mon, 9 Mar 2015 21:28:20 +0100 Subject: [erlang-questions] MNESIA ram-only In-Reply-To: References: Message-ID: Hi Dan, The default is actually disc_opt which then falls back to ram (since there's no schema on disk). My question though is: any risks / other tradeoffs I should be aware of by doing this, instead of having a disk schema? Thanks, r. > On 09/mar/2015, at 21:19, Dan Gudmundsson wrote: > > Sure, you do not need to specify schema_location ram since that is the default if > no schema exists on disc. > > Just be sure that all nodes in cluster are in the nodes() list. > > /Dan > >> On Mon, Mar 9, 2015 at 4:11 PM, Roberto Ostinelli wrote: >> Dear list, >> I am starting MNESIA in RAM only mode, with the option [1]: >> >> -mnesia schema_location ram. >> >> Every time I start a gen_server, I first ensure to add all the other nodes in the island like so: >> >> mnesia:change_config(extra_db_nodes, [node() | nodes()]). >> >> I then create the table I need: >> >> mnesia:create_table(cometa_online_devices, [ >> {type, set}, >> {ram_copies, [node() | nodes()]}, >> {attributes, record_info(fields, my_record)}, >> {index, [#my_record.pid]}, >> {storage_properties, [{ets, [{read_concurrency, true}]}]} >> ]) >> >> I do so mainly to avoid the hassle of creating a schema. As you can see I only use ram tables. >> >> My question here is: is this an appropriate use? What kind of problems may I get myself into by not using a disc schema? >> >> Thank you, >> r. >> >> >> >> [1] http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id76396 >> >> _______________________________________________ >> 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 9 21:47:22 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 9 Mar 2015 16:47:22 -0400 Subject: [erlang-questions] Rebar3 now in Alpha Message-ID: <20150309204722.GB63925@ferdair.local> Hi everyone, Back in November (roughly 4 months ago), Tristan and I announced work on Rebar3 to the rebar mailing list: http://lists.basho.com/pipermail/rebar_lists.basho.com/2014-November/002087.html Today we're happy to announce we're in Alpha. This means that we're generally happy with the current set of features, although we're not sure about their stability and are still open to some changes and additions. Go to https://github.com/rebar/rebar3 if you're interested. So what's new in Rebar3 should you decide to try it with your projects? First of all, Rebar3 has been written with only OTP in mind. If your project isn't OTP, it's more or less gonna be unsupported. If you use OTP releases or OTP applications, it should be helpful. Secondly, we've added a mechanism for 'profiles', meaning your compile options, deps, release options, and so on, can all change depending on context or commands being run (test commands automatically include the 'test' profile, for example). We've gone from the current rebar structure adding all kinds of stuff in your top-level directory to using a single _build/ directory. In this directory, builds for each profile required will be included, avoiding pollution across them. Packages are included, but currently they're all source only until hex.pm gets support for compiled packages. Also they contain Elixir entries until hex.pm gets filtering capability, so right now, most of them won't build either. Source and package dependency conflicts are handled in a deterministic manner, including when upgrading them. See http://www.rebar3.org/v3.0/docs/dependencies-1 for details. We've brought back Dialyzer as a command (and for those of you on rebar 2.0, Tuncer is working on bringing it back there too: https://github.com/rebar/rebar/pull/460). We've also switched from reltool to relx for our release provider, hoping a simpler tool will make for better release adoption: https://github.com/erlware/relx Overall, we have the following list of commands: http://www.rebar3.org/v3.0/docs/commands This is what is currently supported. For anything not there (say, reltool, protobuffs, and so on) we recommend you use a plugin instead. There isn't a huge ecosystem yet, so when you write one, let us know about it. We want to eventually have a plugin index to make it easy to find more tasks people need. Plugin documentation is available at http://www.rebar3.org/v3.0/docs/plugins Thanks everyone, and thanks to contributors who helped us reach the rebar3 alpha version. Particular thanks go to Alisdair Sullivan (@talentdeficit) and James Fish (@fishcakez) for the heavy load of work they've done towards this project. Regards, Fred. From cons@REDACTED Tue Mar 10 11:14:59 2015 From: cons@REDACTED (=?windows-1252?Q?Cons_T_=C5hs?=) Date: Tue, 10 Mar 2015 11:14:59 +0100 Subject: [erlang-questions] Various EDoc questions In-Reply-To: References: Message-ID: On 09 Mar 2015, at 16:39, Pawel Kraszewski wrote: > > * And last but not least ? which documentation form is preferred (if > not both at once), via -spec(...). or via %% @spec ..., as they seem > totally redundant? I heavily use Dialyzer, if this information is > relevant. Use -spec(..) as that will affect both edoc and dialyzer. The same is not true for %% @spec which will only make to edoc. Cons From davidnwelton@REDACTED Tue Mar 10 12:25:24 2015 From: davidnwelton@REDACTED (David Welton) Date: Tue, 10 Mar 2015 12:25:24 +0100 Subject: [erlang-questions] pgapp for Postgres Message-ID: Hi, I thought I'd mention a small project I've put together on top of the epgsql Postgres driver: https://github.com/epgsql/pgapp The idea is to have something a bit higher-level rather than require everyone to eventually put the same thing - or something like it - together themselves. I would not consider it production-ready just yet, but it's worth a look if you want to get up to speed interacting with Postgres in a hurry. One thing I would be happy to do is replace poolboy with something with a bit more intelligence: for instance the ability to relinquish extra connections a bit at a time, rather all at once. Say you set it to run with 5 PG workers normally, but specify an 'overflow capacity' of 10. If you go over 5 and hit 10, it should only relinquish those over some period of time, rather that all at once, to avoid churn. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From gfborn@REDACTED Tue Mar 10 13:08:17 2015 From: gfborn@REDACTED (Grigory Fateyev) Date: Tue, 10 Mar 2015 15:08:17 +0300 Subject: [erlang-questions] Where can I get the list of Erlang bug? Message-ID: <20150310150817.4bafa9c1@gmail.com> Hello guys! I want to spend some time to improve Erlang. Where can I find the list of Erlang bugs that should be fixed? -- Best regards! gfborn [at] gmail [dot] com From essen@REDACTED Tue Mar 10 13:27:41 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 10 Mar 2015 13:27:41 +0100 Subject: [erlang-questions] Where can I get the list of Erlang bug? In-Reply-To: <20150310150817.4bafa9c1@gmail.com> References: <20150310150817.4bafa9c1@gmail.com> Message-ID: <54FEE33D.80205@ninenines.eu> Imprisoned deep in the OTP Team dungeons. More seriously, they told us they would try to make things more open, including a bug tracker, but we are still waiting. Personally I would like to see everything related to the SSL application. The bug tracker doesn't even need to be too complex, just a read-only export of the ticket info and the email of the person assigned would already be very cool. On 03/10/2015 01:08 PM, Grigory Fateyev wrote: > Hello guys! > > I want to spend some time to improve Erlang. Where can I find the list > of Erlang bugs that should be fixed? > -- Lo?c Hoguin http://ninenines.eu From richard.youngkin@REDACTED Tue Mar 10 14:31:51 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Tue, 10 Mar 2015 07:31:51 -0600 Subject: [erlang-questions] Rebar3 now in Alpha Message-ID: Very nice. Thanks to everyone for the new release and the excellent docs! Cheers, Rich Hi everyone, > Back in November (roughly 4 months ago), Tristan and I announced work on > Rebar3 to the rebar mailing list: > > http://lists.basho.com/pipermail/rebar_lists.basho.com/2014-November/002087.html > Today we're happy to announce we're in Alpha. This means that we're > generally > happy with the current set of features, although we're not sure about their > stability and are still open to some changes and additions. Go to > https://github.com/rebar/rebar3 if you're interested. > So what's new in Rebar3 should you decide to try it with your projects? > First of all, Rebar3 has been written with only OTP in mind. If your > project > isn't OTP, it's more or less gonna be unsupported. If you use OTP releases > or > OTP applications, it should be helpful. > Secondly, we've added a mechanism for 'profiles', meaning your compile > options, > deps, release options, and so on, can all change depending on context or > commands being run (test commands automatically include the 'test' > profile, for > example).We've gone from the current rebar structure adding all kinds of > stuff in your > top-level directory to using a single _build/ directory. In this directory, > builds for each profile required will be included, avoiding pollution > across > them. > Packages are included, but currently they're all source only until hex.pm > gets > support for compiled packages. Also they contain Elixir entries until > hex.pm > gets filtering capability, so right now, most of them won't build either. > Source and package dependency conflicts are handled in a deterministic > manner, > including when upgrading them. See > http://www.rebar3.org/v3.0/docs/dependencies-1 for details. > We've brought back Dialyzer as a command (and for those of you on rebar > 2.0, Tuncer is working on bringing it back there too: > https://github.com/rebar/rebar/pull/460). > We've also switched from reltool to relx for our release provider, hoping a > simpler tool will make for better release adoption: > https://github.com/erlware/relx > Overall, we have the following list of commands: > http://www.rebar3.org/v3.0/docs/commands > This is what is currently supported. For anything not there (say, reltool, > protobuffs, and so on) we recommend you use a plugin instead. There isn't a > huge ecosystem yet, so when you write one, let us know about it. We want to > eventually have a plugin index to make it easy to find more tasks people > need. > Plugin documentation is available at > http://www.rebar3.org/v3.0/docs/plugins > Thanks everyone, and thanks to contributors who helped us reach the rebar3 > alpha version. Particular thanks go to Alisdair Sullivan (@talentdeficit) > and > James Fish (@fishcakez) for the heavy load of work they've done towards > this > project. > Regards, > Fred. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.nygren@REDACTED Tue Mar 10 18:34:42 2015 From: anders.nygren@REDACTED (Anders Nygren) Date: Tue, 10 Mar 2015 11:34:42 -0600 Subject: [erlang-questions] Changing primary key with mnesia:transform_table Message-ID: I just discovered that it is not possible to modify the value of the key when using mnesia:transform_table. - I can not find anything in the documentation specifying that it is not allowed. - Why is it not possible to do this? - is there any way to do this except, first doing mnesia:transform_table that does the transformation but without changing the key, and then iterating over the table and modifying the key, i.e. read, delete, and write modified? Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From t@REDACTED Tue Mar 10 21:40:28 2015 From: t@REDACTED (Tristan Sloughter) Date: Tue, 10 Mar 2015 15:40:28 -0500 Subject: [erlang-questions] Rebar3 now in Alpha In-Reply-To: References: Message-ID: <1426020028.1186360.238568985.1C17CB5D@webmail.messagingengine.com> Anyone with questions, as opposed to bug reports which should go on github, there is http://www.rebar3.org/v3.0/discuss as well as #rebar on irc.freenode.net -- Tristan Sloughter t@REDACTED On Tue, Mar 10, 2015, at 08:31 AM, Youngkin, Rich wrote: > Very nice. Thanks to everyone for the new release and the > excellent docs! > > Cheers, Rich > >> Hi everyone, Back in November (roughly 4 months ago), Tristan and I >> announced work on Rebar3 to the rebar mailing list: >> http://lists.basho.com/pipermail/rebar_lists.basho.com/2014-November/002087.html >> Today we're happy to announce we're in Alpha. This means that we're >> generally happy with the current set of features, although we're not >> sure about their stability and are still open to some changes and >> additions. Go to https://github.com/rebar/rebar3 if you're >> interested. So what's new in Rebar3 should you decide to try it with >> your projects? First of all, Rebar3 has been written with only OTP in >> mind. If your project isn't OTP, it's more or less gonna be >> unsupported. If you use OTP releases or OTP applications, it should >> be helpful. Secondly, we've added a mechanism for 'profiles', meaning >> your compile options, deps, release options, and so on, can all >> change depending on context or commands being run (test commands >> automatically include the 'test' profile, for example).We've gone >> from the current rebar structure adding all kinds of stuff in your >> top-level directory to using a single _build/ directory. In this >> directory, builds for each profile required will be included, >> avoiding pollution across them. Packages are included, but currently >> they're all source only until hex.pm[1] gets support for compiled >> packages. Also they contain Elixir entries until hex.pm [2]gets filtering capability, so right now, most of them won't build either. >> Source and package dependency conflicts are handled in a >> deterministic manner, including when upgrading them. See >> http://www.rebar3.org/v3.0/docs/dependencies-1 for details. We've >> brought back Dialyzer as a command (and for those of you on rebar >> 2., Tuncer is working on bringing it back there too: >> https://github.com/rebar/rebar/pull/460). We've also switched from >> reltool to relx for our release provider, hoping a simpler tool >> will make for better release adoption: >> https://github.com/erlware/relx Overall, we have the following list >> of commands: http://www.rebar3.org/v3.0/docs/commands This is what >> is currently supported. For anything not there (say, reltool, >> protobuffs, and so on) we recommend you use a plugin instead. There >> isn't a huge ecosystem yet, so when you write one, let us know >> about it. We want to eventually have a plugin index to make it easy >> to find more tasks people need. Plugin documentation is available >> at http://www.rebar3.org/v3.0/docs/plugins Thanks everyone, and >> thanks to contributors who helped us reach the rebar3 alpha >> version. Particular thanks go to Alisdair Sullivan (@talentdeficit) >> and James Fish (@fishcakez) for the heavy load of work they've done >> towards this project. Regards, Fred. > _________________________________________________ > erlang-questions mailing list erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Links: 3. http://hex.pm/ 4. http://hex.pm/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.lersch@REDACTED Tue Mar 10 22:33:48 2015 From: matthias.lersch@REDACTED (Matthias Lersch) Date: Tue, 10 Mar 2015 22:33:48 +0100 Subject: [erlang-questions] gen_tcp:recv problem Message-ID: <54FF633C.1040103@kairion.de> Hi, I have a problem with gen_tcp:recv... The Body of the first call is missing but shows up at the second call causing a http_error. (full code is shown a the end of the mail) I do a gen_tcp:connect/4 with the options [list, {mode, list}, {reuseaddr, true}, {active, false}, {keepalive, true}, {packet, http}, {send_timeout, timer:seconds(2)}] Then i send a HTTP POST request using gen_tcp:send/2 and go into a "receve loop" with gen_tcp:recv/3 until i get a {error,_} (thats for debugging at the moment and recv timout is set to 10 seconds) my problem is: - On the first call (send) i get all the headers but no content. - On the second call i get the content of the first call at the beginning of the response causing the http_error. I'm sending the request to a node.js service, but the result is the same if i use a dummy apache service with the same response. So i don't think its a problem with the Server I'm sending the request to. The Body of the response (aka content) is always "OK" The received data from the first call looks like this (there is no body with "OK", it ends with http_eoh and then a timeout after 10 seconds) : {ok,{http_response,{1,1},200,"OK"}} {ok,{http_header,0,"X-Powered-By",undefined,"Express"}} {ok,{http_header,42,'Content-Type',undefined,"text/html; charset=utf-8"}} {ok,{http_header,38,'Content-Length',undefined,"2"}} {ok,{http_header,3,'Date',undefined,"Tue, 10 Mar 2015 20:23:05 GMT"}} {ok,{http_header,2,'Connection',undefined,"keep-alive"}} {ok,http_eoh} ...after 10 seconds... {error,timeout} The second call then returns this (notice the OKHTTP/1.1... in the first row, "OK" is the Body from the call before. It should be HTTP/1.1): {ok,{http_error,"OKHTTP/1.1 200 OK\r\n"}} {ok,{http_error,"X-Powered-By: Express\r\n"}} {ok,{http_error,"Content-Type: text/html; charset=utf-8\r\n"}} {ok,{http_error,"Content-Length: 2\r\n"}} {ok,{http_error,"Date: Tue, 10 Mar 2015 20:23:16 GMT\r\n"}} {ok,{http_error,"Connection: keep-alive\r\n"}} {ok,{http_error,"\r\n"}} ...after 10 seconds... {error,timeout} here is the gen_server code im using for my tests. i run the test like this from the erl command line s:start_link(). s:work(1,1). % first call without body s:work(1,1). % second call that fails Thanky for your help! %%%------------------------------------------------------------------- %%% @author mlersch %%% @copyright (C) 2015, %%% @doc %%% %%% @end %%% Created : 20. Feb 2015 11:13 %%%------------------------------------------------------------------- -module(s). -author("mlersch"). %% API -compile(export_all). -behaviour(gen_server). %% API -export([ start_link/0, send/2, reconnect/4]). %% gen_server callbacks -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -define(SERVER, ?MODULE). -record(state, { connection=false, host, port, timeout, opts }). %%%=================================================================== %%% API %%%=================================================================== send(Processor, Data)-> gen_server:call(?MODULE, {send, Processor, Data}). info()-> gen_server:call(?MODULE,info). %%-------------------------------------------------------------------- %% @doc %% Starts the server %% %% @end %%-------------------------------------------------------------------- -spec(start_link() -> {ok, Pid :: pid()} | ignore | {error, Reason :: term()}). start_link() -> process_flag(trap_exit, true), io:format("~p Start~n",[?MODULE]), gen_server:start_link({local, ?SERVER}, ?MODULE, [], []). %%%=================================================================== %%% gen_server callbacks %%%=================================================================== %%-------------------------------------------------------------------- %% @private %% @doc %% Initializes the server %% %% @spec init(Args) -> {ok, State} | %% {ok, State, Timeout} | %% ignore | %% {stop, Reason} %% @end %%-------------------------------------------------------------------- -spec(init(Args :: term()) -> {ok, State :: #state{}} | {ok, State :: #state{}, timeout() | hibernate} | {stop, Reason :: term()} | ignore). init([]) -> State = #state{ host = "localhost", port = 9010, timeout = timer:seconds(2), opts = [list, {mode, list}, {reuseaddr, true}, {active, true}, {keepalive, true}, {packet, http}, {send_timeout, timer:seconds(2)}] }, reconnect(State), {ok, State}. %%-------------------------------------------------------------------- %% @private %% @doc %% Handling call messages %% %% @end %%-------------------------------------------------------------------- -spec(handle_call(Request :: term(), From :: {pid(), Tag :: term()}, State :: #state{}) -> {reply, Reply :: term(), NewState :: #state{}} | {reply, Reply :: term(), NewState :: #state{}, timeout() | hibernate} | {noreply, NewState :: #state{}} | {noreply, NewState :: #state{}, timeout() | hibernate} | {stop, Reason :: term(), Reply :: term(), NewState :: #state{}} | {stop, Reason :: term(), NewState :: #state{}}). handle_call({send, Processor, Data}, From, State) -> % If we are offline, notify the caller case State#state.connection of {ok,Con}-> Request = ["POST /" ++ Processor ++ " HTTP/1.1\r\n" ++ "Content-Length: " ++ integer_to_list(lists:flatlength(Data)) ++ "\r\n" ++ "User-Agent: Erlang Client\r\n" ++ "Content-Type: application/json\r\n" ++ "Host: " ++ State#state.host ++ "\r\n" ++ "Accept: */*\r\n" ++ "\r\n", [Data]], % Try sending the data case send_and_receive(Con, Request) of ok -> {reply, ok, State}; % If sending fails... Error -> % ...Answer the Client with a error gen_server:reply(From, error), io:format("~p Error: ~p~n", [?MODULE, Error]), % ...Close the connection gen_tcp:close(Con), timer:sleep(500), % ...Spawn a Process that trys to reconnect. reconnect(State), % ...Update the connection state {reply, error, State#state{connection = false}} end; _ -> {reply, offline, State} end; handle_call(info, _From, State) -> {reply, State, State}; handle_call(Request, _From, State) -> io:format("~p CALL: ~p~n", [?MODULE, Request]), {reply, ok, State}. %%-------------------------------------------------------------------- %% @private %% @doc %% Handling cast messages %% %% @end %%-------------------------------------------------------------------- -spec(handle_cast(Request :: term(), State :: #state{}) -> {noreply, NewState :: #state{}} | {noreply, NewState :: #state{}, timeout() | hibernate} | {stop, Reason :: term(), NewState :: #state{}}). handle_cast({connected, Connection}, State) -> io:format("~p Connected: ~p~n", [?MODULE, Connection]), {noreply, State#state{connection = Connection}}; handle_cast(Request, State) -> io:format("~p CAST: ~p~n", [?MODULE, Request]), {noreply, State}. %%-------------------------------------------------------------------- %% @private %% @doc %% Handling all non call/cast messages %% %% @spec handle_info(Info, State) -> {noreply, State} | %% {noreply, State, Timeout} | %% {stop, Reason, State} %% @end %%-------------------------------------------------------------------- -spec(handle_info(Info :: timeout() | term(), State :: #state{}) -> {noreply, NewState :: #state{}} | {noreply, NewState :: #state{}, timeout() | hibernate} | {stop, Reason :: term(), NewState :: #state{}}). handle_info({tcp_closed, _}, State) -> io:format("~p Connection closed!~n", [?MODULE]), reconnect(State), {noreply, State#state{connection = false}}; handle_info(Info, State) -> io:format("~p INFO: ~p~n", [?MODULE, Info]), {noreply, State}. %%-------------------------------------------------------------------- %% @private %% @doc %% This function is called by a gen_server when it is about to %% terminate. It should be the opposite of Module:init/1 and do any %% necessary cleaning up. When it returns, the gen_server terminates %% with Reason. The return value is ignored. %% %% @spec terminate(Reason, State) -> void() %% @end %%-------------------------------------------------------------------- -spec(terminate(Reason :: (normal | shutdown | {shutdown, term()} | term()), State :: #state{}) -> term()). terminate(Reason, _State) -> io:format("~p TERMINATE: ~p~n", [?MODULE, Reason]), ok. %%-------------------------------------------------------------------- %% @private %% @doc %% Convert process state when code is changed %% %% @spec code_change(OldVsn, State, Extra) -> {ok, NewState} %% @end %%-------------------------------------------------------------------- -spec(code_change(OldVsn :: term() | {down, term()}, State :: #state{}, Extra :: term()) -> {ok, NewState :: #state{}} | {error, Reason :: term()}). code_change(_OldVsn, State, _Extra) -> {ok, State}. %%%=================================================================== %%% Internal functions %%%=================================================================== %% This helper function sends the request to the server and parses the response %% to look in it for a status 200 code. If it finds a 200 we return ok otherwise error. %% by default we use active connections, when we are in idle to get info messages about %% deconnections into handle_info/2 %% but here we must change to passive mode, so we are able to parse the response of this %% send operations. disconnect messages wont show up in passive mode but will pop up when %% we switch bach to active mode again (even if the ocured during passive mode). send_and_receive(Con, Request)-> inet:setopts(Con, [{active, false}]), Response = case gen_tcp:send(Con, Request) of ok -> parse_response(Con); E -> E end, inet:setopts(Con, [{active, true}]), Response. parse_response(Con)->parse_response(Con, error). parse_response(Con, State)-> R = gen_tcp:recv(Con, 0, timer:seconds(10)), io:format("PR: ~p~n",[R]), case R of {ok,{http_response,_,200,_}} -> parse_response(Con, ok); {ok,http_eoh} -> io:format("PRX: ~p~n",[gen_tcp:recv(Con, 0, timer:seconds(10))]), State; {error, E} -> {error, E}; _ -> parse_response(Con, State) end. reconnect(State)-> spawn_link(?MODULE, reconnect, [self(), State, calendar:local_time(), 1]). reconnect(Pid, State, Started, Tries)-> io:format("~p Connecting to host ~p on port ~p~n",[?MODULE, State#state.host, State#state.port]), case gen_tcp:connect(State#state.host, State#state.port, State#state.opts, State#state.timeout) of {ok, Connection} -> io:format("~p Reconnect changing controlling process: ~p~n",[?MODULE, gen_tcp:controlling_process(Connection, Pid)]), gen_server:cast(?MODULE, {connected, {ok, Connection}}); E -> io:format("~p Reconnection failed ~p (Tried it ~p times since ~p). Waiting 2sec. till retry!~n", [?MODULE, E, Tries, Started]), timer:sleep(timer:seconds(2)), reconnect(Pid, State, Started, Tries+1) end. %%%=================================================================== %%% Debug stuff %%%=================================================================== loop(Max)-> lists:foreach(fun(_)-> timer:sleep(100), spawn(fun()-> send("processgaac", "{\"_id\":{\"$oid\":\"53B382F4BE53EE3946137430\"},\"sid\":\"07101a57ce294750bb36fa72e2ffab5d\",\"eid\":1566,\"cd\":{\"$date\":1404273396000},\"t\":\"gaac\",\"p\":{\"ua\":\"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0\",\"pt\":\"search_result\",\"rt\":\"internal\",\"gs\":[{\"g\":\"08006309\",\"p\":1650},{\"g\":\"04431464\",\"p\":1429},{\"g\":\"03932773\",\"p\":696},{\"g\":\"07563999\",\"p\":825},{\"g\":\"09100275\",\"p\":5089},{\"g\":\"06426800\",\"p\":2240},{\"g\":\"10417853\",\"p\":1180},{\"g\":\"02096458\",\"p\":1365},{\"g\":\"08798173\",\"p\":3897},{\"g\":\"03531850\",\"p\":1243},{\"g\":\"00188357\",\"p\":412},{\"g\":\"09296203\",\"p\":2495},{\"g\":\"05566143\",\"p\":1498},{\"g\":\"08006456\",\"p\":1467},{\"g\":\"04347717\",\"p\":2199},{\"g\":\"08006410\",\"p\":4499},{\"g\":\"09374110\",\"p\":3897},{\"g\":\"04187656\",\"p\":691},{\"g\":\"05010397\",\"p\":1075},{\"g\":\"07727923\",\"p\":493}],\"cats\":[\"1100068\",\"1100068\",\"1100068\",\"1100071\",\"1100043\",\"1100015\",\"1100015\",\"1100029\",\"1100355\",\"1100355\",\"1100196\",\"1100114\",\"1100013\",\"1100021\",\"1100021\",\"1100021\",\"1100021\",\"1100021\",\"1100170\",\"1571\",\"1100014\",\"1100117\",\"1100233\",\"1100107\",\"1100096\",\"1100467\",\"1100094\",\"1100094\",\"1100013\",\"1100014\",\"1100014\",\"1100029\",\"1100015\",\"1100015\",\"1100017\",\"1100463\",\"1100034\",\"1100109\",\"1440\",\"1100114\",\"1100109\",\"1440\",\"1100177\",\"1100013\",\"1100191\",\"1100094\",\"1100191\",\"1100029\",\"1100029\",\"1100048\",\"1100043\",\"1100016\",\"1100210\",\"1100016\",\"1100463\",\"1226\"],\"catsc\":[\"AR02AA16\",\"79680\",\"22172\",\"30365\",\"AR01AC03\",\"24009\",\"79658\",\"66403\",\"30365\",\"22294\",\"BX01\",\"71445\",\"81085\",\"24510\",\"30365\",\"22294\",\"AD11AX01\",\"82323\",\"30365\",\"22294\",\"30365\",\"22294\",\"BB03Z\",\"81644\",\"81629\",\"25123\",\"22183\",\"22182\",\"30365\",\"30365\",\"BB01A\",\"24577\",\"66407\",\"30365\",\"AD01AE16\",\"30365\",\"AD08AC\",\"24512\",\"22206\",\"30365\",\"AN05CX\",\"81736\",\"22192\",\"30365\",\"BB03Z\",\"77677\",\"66409\",\"66407\",\"30365\",\"BX01\",\"71446\",\"79609\",\"22171\",\"30365\",\"BC01D\",\"30365\",\"BB03D\",\"82323\",\"25125\",\"22204\",\"30365\",\"22294\",\"AD11AX01\",\"82997\",\"82323\",\"25125\",\"22204\",\"32455\",\"30365\",\"22294\",\"BB03Z\",\"24783\",\"81736\",\"81083\",\"81082\",\"81087\",\"39604\",\"30365\",\"AS01GX07\",\"24009\",\"22220\",\"22196\",\"79610\",\"30365\",\"22294\",\"BC01D\",\"24728\",\"30365\",\"23432\",\"30365\"],\"catsx\":[\"30365\",\"30365\",\"22294\",\"30365\",\"22294\",\"82323\",\"30365\",\"22294\",\"30365\",\"22294\",\"30365\",\"30365\",\"30365\",\"30365\",\"30365\",\"30365\",\"77677\",\"30365\",\"30365\",\"30365\",\"82323\",\"30365\",\"22294\",\"82997\",\"82323\",\"30365\",\"22294\",\"39604\",\"30365\",\"30365\",\"22294\",\"30365\",\"23432\",\"30365\"],\"fpid\":\"/aktionsartikel\",\"lt\":\"list\",\"lp\":1},\"r\":{\"s\":[{\"slid\":\"high\",\"cid\":2498,\"scr\":100000000,\"f\":1}]},\"ti\":200000000,\"to\":false,\"at\":53596,\"dv\":8,\"agg\":[],\"pad\":\"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"}") end) end, lists:seq(1,Max)). work(Loops, Max)-> lists:foreach(fun(_)-> spawn(s,loop,[Max]) end,lists:seq(1,Loops)). -- ________________________________________ Matthias Lersch, Senior Software Architect Tel.: +49 69 972 69 197; Fax: +49 69 972 69 204; Email: matthias.lersch@REDACTED Kairion GmbH, Gutleutstra?e 30, D-60329 Frankfurt Internet: http://www.kairion.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From zkessin@REDACTED Wed Mar 11 06:56:31 2015 From: zkessin@REDACTED (Zachary Kessin) Date: Wed, 11 Mar 2015 07:56:31 +0200 Subject: [erlang-questions] New Erlang EBook In-Reply-To: References: <54F595FA.9060006@gmail.com> <54F729C0.1010607@ninenines.eu> <20150304163319.GB57078@ferdair.local> Message-ID: <54FFD90F.4000903@gmail.com> I put a sample chapter (On Shrinking) online http://www.erlang-quickcheck-book.com/sample/ --Zach On 03/05/2015 01:50 PM, Roger Lipscombe wrote: >> If Zach wishes to charge money for his book, that's his prerogative. >> He's written before and is likely aware of the consequences (Will >> readers expense it at work, pirate it at home, borrow it from a library? >> Does pricing change the perception people have from the book in terms of >> quality?) and able to choose what he's comfortable with. > Absolutely agree with this. It is totally Zach's prerogative. Doesn't > make me stop wishing that there was a sample chapter available for > free, though. $39 seems like a lot to plunk down sight unseen. For > this reason alone, I'll be holding back. > > Contrast this with the fact that I just this morning bought "Your Code > As a Crime Scene" from Pragpub based on reading a couple of sample > pages. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From eric.pailleau@REDACTED Wed Mar 11 12:02:45 2015 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Wed, 11 Mar 2015 12:02:45 +0100 Subject: [erlang-questions] TR: Re: Where can I get the list of Erlang bug? In-Reply-To: References: Message-ID: <4akhdjpf9vprs9acn002bm88.1426071765059@email.android.com> ---- Message original ---- Objet?: Re: [erlang-questions] Where can I get the list of Erlang bug? Envoy??: 11 mars 2015 11:58 De?: ?ric Pailleau ??: Grigory Fateyev Cc?: In the source code... Joke. Like Lo?c said a bug tracker would be a great help in Erlang enhancement. BTW the "what you could do" is empty since the beginning. This could be nice that Otp team guys trust community in doing things that they won t do themselves... Like adding libraries existing in Java and missing in Erlang. I think to something: a p12 file manager for example. Regards "Envoy? depuis mon mobile " Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.lersch@REDACTED Wed Mar 11 11:43:13 2015 From: matthias.lersch@REDACTED (Matthias Lersch) Date: Wed, 11 Mar 2015 11:43:13 +0100 Subject: [erlang-questions] gen_tcp:recv problem (solved) In-Reply-To: <54FF633C.1040103@kairion.de> References: <54FF633C.1040103@kairion.de> Message-ID: <55001C41.4090706@kairion.de> Hi, I found the solution. I had to switch to raw mode after http_eoh and do a gen_tcp:recv/3 wih 'Content-Length' Am 10.03.2015 um 22:33 schrieb Matthias Lersch: > Hi, > > I have a problem with gen_tcp:recv... > The Body of the first call is missing but shows up at the second call > causing a http_error. (full code is shown a the end of the mail) > > I do a gen_tcp:connect/4 with the options > [list, {mode, list}, {reuseaddr, true}, {active, false}, {keepalive, > true}, {packet, http}, {send_timeout, timer:seconds(2)}] > > Then i send a HTTP POST request using gen_tcp:send/2 and go into a > "receve loop" with gen_tcp:recv/3 until i get a {error,_} (thats for > debugging at the moment and recv timout is set to 10 seconds) > > my problem is: > - On the first call (send) i get all the headers but no content. > - On the second call i get the content of the first call at the > beginning of the response causing the http_error. > > > I'm sending the request to a node.js service, but the result is the > same if i use a dummy apache service with the same response. > So i don't think its a problem with the Server I'm sending the request > to. > The Body of the response (aka content) is always "OK" > > The received data from the first call looks like this (there is no > body with "OK", it ends with http_eoh and then a timeout after 10 > seconds) : > > {ok,{http_response,{1,1},200,"OK"}} > {ok,{http_header,0,"X-Powered-By",undefined,"Express"}} > {ok,{http_header,42,'Content-Type',undefined,"text/html; > charset=utf-8"}} > {ok,{http_header,38,'Content-Length',undefined,"2"}} > {ok,{http_header,3,'Date',undefined,"Tue, 10 Mar 2015 20:23:05 GMT"}} > {ok,{http_header,2,'Connection',undefined,"keep-alive"}} > {ok,http_eoh} > ...after 10 seconds... > {error,timeout} > > The second call then returns this (notice the OKHTTP/1.1... in the > first row, "OK" is the Body from the call before. It should be HTTP/1.1): > > {ok,{http_error,"OKHTTP/1.1 200 OK\r\n"}} > {ok,{http_error,"X-Powered-By: Express\r\n"}} > {ok,{http_error,"Content-Type: text/html; charset=utf-8\r\n"}} > {ok,{http_error,"Content-Length: 2\r\n"}} > {ok,{http_error,"Date: Tue, 10 Mar 2015 20:23:16 GMT\r\n"}} > {ok,{http_error,"Connection: keep-alive\r\n"}} > {ok,{http_error,"\r\n"}} > ...after 10 seconds... > {error,timeout} > > > > here is the gen_server code im using for my tests. > i run the test like this from the erl command line > s:start_link(). > s:work(1,1). % first call without body > s:work(1,1). % second call that fails > > Thanky for your help! > > > %%%------------------------------------------------------------------- > %%% @author mlersch > %%% @copyright (C) 2015, > %%% @doc > %%% > %%% @end > %%% Created : 20. Feb 2015 11:13 > %%%------------------------------------------------------------------- > -module(s). > -author("mlersch"). > > %% API > -compile(export_all). > > -behaviour(gen_server). > > %% API > -export([ > start_link/0, > send/2, > reconnect/4]). > > %% gen_server callbacks > -export([init/1, > handle_call/3, > handle_cast/2, > handle_info/2, > terminate/2, > code_change/3]). > > -define(SERVER, ?MODULE). > > -record(state, { > connection=false, > host, > port, > timeout, > opts > }). > > > %%%=================================================================== > %%% API > %%%=================================================================== > > send(Processor, Data)-> > gen_server:call(?MODULE, {send, Processor, Data}). > > info()-> > gen_server:call(?MODULE,info). > > %%-------------------------------------------------------------------- > %% @doc > %% Starts the server > %% > %% @end > %%-------------------------------------------------------------------- > -spec(start_link() -> > {ok, Pid :: pid()} | ignore | {error, Reason :: term()}). > start_link() -> > process_flag(trap_exit, true), > io:format("~p Start~n",[?MODULE]), > gen_server:start_link({local, ?SERVER}, ?MODULE, [], []). > > %%%=================================================================== > %%% gen_server callbacks > %%%=================================================================== > > %%-------------------------------------------------------------------- > %% @private > %% @doc > %% Initializes the server > %% > %% @spec init(Args) -> {ok, State} | > %% {ok, State, Timeout} | > %% ignore | > %% {stop, Reason} > %% @end > %%-------------------------------------------------------------------- > -spec(init(Args :: term()) -> > {ok, State :: #state{}} | {ok, State :: #state{}, timeout() | > hibernate} | > {stop, Reason :: term()} | ignore). > init([]) -> > > State = #state{ > host = "localhost", > port = 9010, > timeout = timer:seconds(2), > opts = [list, {mode, list}, {reuseaddr, true}, {active, true}, > {keepalive, true}, {packet, http}, {send_timeout, timer:seconds(2)}] > }, > > reconnect(State), > {ok, State}. > > %%-------------------------------------------------------------------- > %% @private > %% @doc > %% Handling call messages > %% > %% @end > %%-------------------------------------------------------------------- > -spec(handle_call(Request :: term(), From :: {pid(), Tag :: term()}, > State :: #state{}) -> > {reply, Reply :: term(), NewState :: #state{}} | > {reply, Reply :: term(), NewState :: #state{}, timeout() | hibernate} | > {noreply, NewState :: #state{}} | > {noreply, NewState :: #state{}, timeout() | hibernate} | > {stop, Reason :: term(), Reply :: term(), NewState :: #state{}} | > {stop, Reason :: term(), NewState :: #state{}}). > > handle_call({send, Processor, Data}, From, State) -> > > % If we are offline, notify the caller > case State#state.connection of > > {ok,Con}-> > > Request = > ["POST /" ++ Processor ++ " HTTP/1.1\r\n" > ++ "Content-Length: " ++ > integer_to_list(lists:flatlength(Data)) ++ "\r\n" > ++ "User-Agent: Erlang Client\r\n" > ++ "Content-Type: application/json\r\n" > ++ "Host: " ++ State#state.host ++ "\r\n" > ++ "Accept: */*\r\n" > ++ "\r\n", [Data]], > > % Try sending the data > case send_and_receive(Con, Request) of > ok -> {reply, ok, State}; > > % If sending fails... > Error -> > % ...Answer the Client with a error > gen_server:reply(From, error), > io:format("~p Error: ~p~n", [?MODULE, Error]), > > % ...Close the connection > gen_tcp:close(Con), > timer:sleep(500), > > % ...Spawn a Process that trys to reconnect. > reconnect(State), > > % ...Update the connection state > {reply, error, State#state{connection = false}} > > end; > > _ -> {reply, offline, State} > end; > > handle_call(info, _From, State) -> > {reply, State, State}; > > handle_call(Request, _From, State) -> > io:format("~p CALL: ~p~n", [?MODULE, Request]), > {reply, ok, State}. > > %%-------------------------------------------------------------------- > %% @private > %% @doc > %% Handling cast messages > %% > %% @end > %%-------------------------------------------------------------------- > -spec(handle_cast(Request :: term(), State :: #state{}) -> > {noreply, NewState :: #state{}} | > {noreply, NewState :: #state{}, timeout() | hibernate} | > {stop, Reason :: term(), NewState :: #state{}}). > handle_cast({connected, Connection}, State) -> > io:format("~p Connected: ~p~n", [?MODULE, Connection]), > {noreply, State#state{connection = Connection}}; > > handle_cast(Request, State) -> > io:format("~p CAST: ~p~n", [?MODULE, Request]), > {noreply, State}. > > %%-------------------------------------------------------------------- > %% @private > %% @doc > %% Handling all non call/cast messages > %% > %% @spec handle_info(Info, State) -> {noreply, State} | > %% {noreply, State, Timeout} | > %% {stop, Reason, State} > %% @end > %%-------------------------------------------------------------------- > -spec(handle_info(Info :: timeout() | term(), State :: #state{}) -> > {noreply, NewState :: #state{}} | > {noreply, NewState :: #state{}, timeout() | hibernate} | > {stop, Reason :: term(), NewState :: #state{}}). > > handle_info({tcp_closed, _}, State) -> > io:format("~p Connection closed!~n", [?MODULE]), > reconnect(State), > {noreply, State#state{connection = false}}; > > handle_info(Info, State) -> > io:format("~p INFO: ~p~n", [?MODULE, Info]), > {noreply, State}. > > %%-------------------------------------------------------------------- > %% @private > %% @doc > %% This function is called by a gen_server when it is about to > %% terminate. It should be the opposite of Module:init/1 and do any > %% necessary cleaning up. When it returns, the gen_server terminates > %% with Reason. The return value is ignored. > %% > %% @spec terminate(Reason, State) -> void() > %% @end > %%-------------------------------------------------------------------- > -spec(terminate(Reason :: (normal | shutdown | {shutdown, term()} | > term()), > State :: #state{}) -> term()). > terminate(Reason, _State) -> > io:format("~p TERMINATE: ~p~n", [?MODULE, Reason]), > ok. > > %%-------------------------------------------------------------------- > %% @private > %% @doc > %% Convert process state when code is changed > %% > %% @spec code_change(OldVsn, State, Extra) -> {ok, NewState} > %% @end > %%-------------------------------------------------------------------- > -spec(code_change(OldVsn :: term() | {down, term()}, State :: #state{}, > Extra :: term()) -> > {ok, NewState :: #state{}} | {error, Reason :: term()}). > code_change(_OldVsn, State, _Extra) -> > {ok, State}. > > %%%=================================================================== > %%% Internal functions > %%%=================================================================== > > > > %% This helper function sends the request to the server and parses the > response > %% to look in it for a status 200 code. If it finds a 200 we return ok > otherwise error. > %% by default we use active connections, when we are in idle to get > info messages about > %% deconnections into handle_info/2 > %% but here we must change to passive mode, so we are able to parse > the response of this > %% send operations. disconnect messages wont show up in passive mode > but will pop up when > %% we switch bach to active mode again (even if the ocured during > passive mode). > send_and_receive(Con, Request)-> > inet:setopts(Con, [{active, false}]), > Response = > case gen_tcp:send(Con, Request) of > ok -> parse_response(Con); > E -> E > end, > inet:setopts(Con, [{active, true}]), > Response. > > > parse_response(Con)->parse_response(Con, error). > parse_response(Con, State)-> > R = gen_tcp:recv(Con, 0, timer:seconds(10)), > io:format("PR: ~p~n",[R]), > case R of > {ok,{http_response,_,200,_}} -> parse_response(Con, ok); > {ok,http_eoh} -> > io:format("PRX: ~p~n",[gen_tcp:recv(Con, 0, timer:seconds(10))]), > State; > {error, E} -> {error, E}; > _ -> parse_response(Con, State) > end. > > reconnect(State)-> > spawn_link(?MODULE, reconnect, [self(), State, > calendar:local_time(), 1]). > > reconnect(Pid, State, Started, Tries)-> > io:format("~p Connecting to host ~p on port ~p~n",[?MODULE, > State#state.host, State#state.port]), > case gen_tcp:connect(State#state.host, State#state.port, > State#state.opts, State#state.timeout) of > {ok, Connection} -> > io:format("~p Reconnect changing controlling process: > ~p~n",[?MODULE, gen_tcp:controlling_process(Connection, Pid)]), > gen_server:cast(?MODULE, {connected, {ok, Connection}}); > E -> io:format("~p Reconnection failed ~p (Tried it ~p times since > ~p). Waiting 2sec. till retry!~n", [?MODULE, E, Tries, Started]), > timer:sleep(timer:seconds(2)), > reconnect(Pid, State, Started, Tries+1) > end. > > > > %%%=================================================================== > %%% Debug stuff > %%%=================================================================== > loop(Max)-> > lists:foreach(fun(_)-> > timer:sleep(100), > spawn(fun()-> > send("processgaac", > "{\"_id\":{\"$oid\":\"53B382F4BE53EE3946137430\"},\"sid\":\"07101a57ce294750bb36fa72e2ffab5d\",\"eid\":1566,\"cd\":{\"$date\":1404273396000},\"t\":\"gaac\",\"p\":{\"ua\":\"Mozilla/5.0 > (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 > Firefox/30.0\",\"pt\":\"search_result\",\"rt\":\"internal\",\"gs\":[{\"g\":\"08006309\",\"p\":1650},{\"g\":\"04431464\",\"p\":1429},{\"g\":\"03932773\",\"p\":696},{\"g\":\"07563999\",\"p\":825},{\"g\":\"09100275\",\"p\":5089},{\"g\":\"06426800\",\"p\":2240},{\"g\":\"10417853\",\"p\":1180},{\"g\":\"02096458\",\"p\":1365},{\"g\":\"08798173\",\"p\":3897},{\"g\":\"03531850\",\"p\":1243},{\"g\":\"00188357\",\"p\":412},{\"g\":\"09296203\",\"p\":2495},{\"g\":\"05566143\",\"p\":1498},{\"g\":\"08006456\",\"p\":1467},{\"g\":\"04347717\",\"p\":2199},{\"g\":\"08006410\",\"p\":4499},{\"g\":\"09374110\",\"p\":3897},{\"g\":\"04187656\",\"p\":691},{\"g\":\"05010397\",\"p\":1075},{\"g\":\"07727923\",\"p\":493}],\"cats\":[\"1100068\",\"1100068\",\"1100068\",\"1100071\",\"1100043\",\"1100015\",\"1100015\",\"1100029\",\"1100355\",\"1100355\",\"1100196\",\"1100114\",\"1100013\",\"1100021\",\"1100021\",\"1100021\",\"1100021\",\"1100021\",\"1100170\",\"1571\",\"1100014\",\"1100117\",\"1100233\",\"1100107\", > \"1100096\",\"1100467\",\"1100094\",\"1100094\",\"1100013\",\"1100014\",\"1100014\",\"1100029\",\"1100015\",\"1100015\",\"1100017\",\"1100463\",\"1100034\",\"1100109\",\"1440\",\"1100114\",\"1100109\",\"1440\",\"1100177\",\"1100013\",\"1100191\",\"1100094\",\"1100191\",\"1100029\",\"1100029\",\"1100048\",\"1100043\",\"1100016\",\"1100210\",\"1100016\",\"1100463\",\"1226\"],\"catsc\":[\"AR02AA16\",\"79680\",\"22172\",\"30365\",\"AR01AC03\",\"24009\",\"79658\",\"66403\",\"30365\",\"22294\",\"BX01\",\"71445\",\"81085\",\"24510\",\"30365\",\"22294\",\"AD11AX01\",\"82323\",\"30365\",\"22294\",\"30365\",\"22294\",\"BB03Z\",\"81644\",\"81629\",\"25123\",\"22183\",\"22182\",\"30365\",\"30365\",\"BB01A\",\"24577\",\"66407\",\"30365\",\"AD01AE16\",\"30365\",\"AD08AC\",\"24512\",\"22206\",\"30365\",\"AN05CX\",\"81736\",\"22192\",\"30365\",\"BB03Z\",\"77677\",\"66409\",\"66407\",\"30365\",\"BX01\",\"71446\",\"79609\",\"22171\",\"30365\",\"BC01D\",\"30365\",\"BB03D\",\"82323\",\"25125\",\"22204\", > \"30365\",\"22294\",\"AD11AX01\",\"82997\",\"82323\",\"25125\",\"22204\",\"32455\",\"30365\",\"22294\",\"BB03Z\",\"24783\",\"81736\",\"81083\",\"81082\",\"81087\",\"39604\",\"30365\",\"AS01GX07\",\"24009\",\"22220\",\"22196\",\"79610\",\"30365\",\"22294\",\"BC01D\",\"24728\",\"30365\",\"23432\",\"30365\"],\"catsx\":[\"30365\",\"30365\",\"22294\",\"30365\",\"22294\",\"82323\",\"30365\",\"22294\",\"30365\",\"22294\",\"30365\",\"30365\",\"30365\",\"30365\",\"30365\",\"30365\",\"77677\",\"30365\",\"30365\",\"30365\",\"82323\",\"30365\",\"22294\",\"82997\",\"82323\",\"30365\",\"22294\",\"39604\",\"30365\",\"30365\",\"22294\",\"30365\",\"23432\",\"30365\"],\"fpid\":\"/aktionsartikel\",\"lt\":\"list\",\"lp\":1},\"r\":{\"s\":[{\"slid\":\"high\",\"cid\":2498,\"scr\":100000000,\"f\":1}]},\"ti\":200000000,\"to\":false,\"at\":53596,\"dv\":8,\"agg\":[],\"pad\":\"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"}") > end) > end, > lists:seq(1,Max)). > > work(Loops, Max)-> > lists:foreach(fun(_)-> spawn(s,loop,[Max]) end,lists:seq(1,Loops)). > > -- > ________________________________________ > Matthias Lersch, Senior Software Architect > Tel.: +49 69 972 69 197; Fax: +49 69 972 69 204; Email: > matthias.lersch@REDACTED > Kairion GmbH, Gutleutstra?e 30, D-60329 Frankfurt > Internet: http://www.kairion.de > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- ________________________________________ Matthias Lersch, Senior Software Architect Tel.: +49 69 972 69 197; Fax: +49 69 972 69 204; Email: matthias.lersch@REDACTED Kairion GmbH, Gutleutstra?e 30, D-60329 Frankfurt Internet: http://www.kairion.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.youngkin@REDACTED Wed Mar 11 14:12:45 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Wed, 11 Mar 2015 07:12:45 -0600 Subject: [erlang-questions] New Erlang EBook Message-ID: Hi Zach, Can you post a table of contents on the website? Thanks, Rich Message: 8 > Date: Wed, 11 Mar 2015 07:56:31 +0200 > From: Zachary Kessin > To: erlang-questions@REDACTED > Subject: Re: [erlang-questions] New Erlang EBook > Message-ID: <54FFD90F.4000903@REDACTED> > Content-Type: text/plain; charset=windows-1252; format=flowed > I put a sample chapter (On Shrinking) online > http://www.erlang-quickcheck-book.com/sample/ > --Zach > On 03/05/2015 01:50 PM, Roger Lipscombe wrote: > >> If Zach wishes to charge money for his book, that's his prerogative. > >> He's written before and is likely aware of the consequences (Will > >> readers expense it at work, pirate it at home, borrow it from a library? > >> Does pricing change the perception people have from the book in terms of > >> quality?) and able to choose what he's comfortable with. > > Absolutely agree with this. It is totally Zach's prerogative. Doesn't > > make me stop wishing that there was a sample chapter available for > > free, though. $39 seems like a lot to plunk down sight unseen. For > > this reason alone, I'll be holding back. > > > > Contrast this with the fact that I just this morning bought "Your Code > > As a Crime Scene" from Pragpub based on reading a couple of sample > > pages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.youngkin@REDACTED Wed Mar 11 22:29:53 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Wed, 11 Mar 2015 15:29:53 -0600 Subject: [erlang-questions] Binary data hiding sasl log entries? Message-ID: Hi all, I was wondering if anyone has seen binary data in a sasl log and what might be causing it. I'm seeing thousands and thousands of "^@" characters. In addition, I'm not seeing expected startup messages and I'm wondering if this info has been obscured by the binary data. I only see this occur at the beginning of a sasl log. I'm using R15B03. Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.youngkin@REDACTED Wed Mar 11 22:57:50 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Wed, 11 Mar 2015 15:57:50 -0600 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit Message-ID: Hi, I'm a little confused about when gen_server:terminate/2 will be called. Mostly just in one area WRT a recommendation in LYSE, the "Clients & Servers" and the "Who Supervises the Supervisors" chapters to call trap_exit in the init/1 function. To quote: "terminate/2 will also be called when its parent (the process that spawned it) dies, if and only if the gen_server is trapping exits." and... "Two things go on in the init/1 function. First we start trapping exits. If you recall the description of the terminate/2 from the Generic Servers chapter , we need to do this if we want terminate/2 to be called when the server's parent shuts down its children." The Erlang documentation on Supervisors states "Note that all child processes implemented using the standard OTP behavior modules automatically adhere to the shutdown protocol.". I'm having trouble reconciling these LYSE with the Erlang Supervisor docs. I'm assuming they're both correct and that the LYSE comment refers to gen_servers that aren't managed by a supervisor. Is this correct or is there another explanation for the seemingly contradictory statements? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Wed Mar 11 23:17:03 2015 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 11 Mar 2015 15:17:03 -0700 Subject: [erlang-questions] Where can I get the list of Erlang bug? In-Reply-To: <54FEE33D.80205@ninenines.eu> References: <20150310150817.4bafa9c1@gmail.com> <54FEE33D.80205@ninenines.eu> Message-ID: <5500BEDF.5010407@gmail.com> On 03/10/2015 05:27 AM, Lo?c Hoguin wrote: > Imprisoned deep in the OTP Team dungeons. > > More seriously, they told us they would try to make things more open, including a bug tracker, but we are still waiting. Personally I would like to see everything related to the SSL application. > > The bug tracker doesn't even need to be too complex, just a read-only export of the ticket info and the email of the person assigned would already be very cool. Ideally the bug tracker would also be tracking features that are currently in development, planned, and those features that are not in scope for software development at Ericsson (i.e., in the OTP Team dungeons). For example, I have seen garbage collection latency grow under load during loadtesting when comparing R16B03-1 and 17.4, but it is unclear if this is something which is getting worse that will get resolved in the future when it is seen during testing at Ericsson, or if it is a known issue that is being actively pursued. Otherwise, it is hard to have any degree of confidence in Erlang/OTP, without a certain level of basic transparency. From mononcqc@REDACTED Thu Mar 12 00:20:41 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 11 Mar 2015 19:20:41 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: Message-ID: <20150311232040.GA1523@ferdmbp.local> On 03/11, Youngkin, Rich wrote: > "terminate/2 will also be called when its parent (the process that spawned > it) dies, if and only if the gen_server is trapping exits." > > [...] > > The Erlang documentation on Supervisors states "Note that all child > processes implemented using the standard OTP behavior modules automatically > adhere to the shutdown protocol.". I'm having trouble reconciling these > LYSE with the Erlang Supervisor docs. > > Thanks, > Rich The references I found to the shutdown protocol is: http://www.erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html#shutdown "The supervisor process sends an exit signal to the child process and waits for acknowledgment. The child process should handle the {'EXIT',ParentPid,shutdown} message and terminate with reason shutdown if it traps exit signals." The last line here is important -- if it traps exit signals. This is in agreement with what LYSE mentions. If you don't trap exit signals, you can't get the signal, it just kills the process directly. Regards, Fred. From imantc@REDACTED Thu Mar 12 00:50:08 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 00:50:08 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: <20150311232040.GA1523@ferdmbp.local> References: <20150311232040.GA1523@ferdmbp.local> Message-ID: Although not related to terminate question, let me ask another question about sup-child linkeage: If StartFunc defined in child spec calls gen_server:start, will supervisor restart crashed instance of that child if permanent restart is specified in the child spec? http://www.erlang.org/doc/man/supervisor.html : The start function *must create and link to* the child process Yet it is possible to specify gs:start instead of gs:start_link. Would a link still be created in this case? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Thu Mar 12 01:11:09 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 11 Mar 2015 20:11:09 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> Message-ID: <20150312001108.GB1523@ferdmbp.local> On 03/12, Imants Cekusins wrote: > http://www.erlang.org/doc/man/supervisor.html : > The start function *must create and link to* the child process > > Yet it is possible to specify gs:start instead of gs:start_link. Would a > link still be created in this case? The documentation is right. The function should create a link otherwise it won't work. If you don't pass in a function that creates a link, then no link will be created. The supervisor won't supervise anything except when forcing a termination (supervisors set up monitors to know when a child has died following the order to kill them, and when to brutal_kill them) From imantc@REDACTED Thu Mar 12 01:42:01 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 01:42:01 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: <20150312001108.GB1523@ferdmbp.local> References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> Message-ID: Thank you very much Fred! Btw gen_server's terminate is always called before gs process stops, no? the only exceptions are: 1) gs process crash 2) gs is unconditionally terminated using exit(Child,kill). In other words, gs' own terminate is internal gs business - not related to supervision tree. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Thu Mar 12 02:10:17 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 02:10:17 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> Message-ID: > gs' own terminate is internal gs business - not related to supervision tree. This may not sound quite right so I'll illustrate: Even if gs instance G is started via gs:start by any process (not necessarily a sup), G's terminate would still be called - let's say, after G's handle_cast returns {stop, normal, State} ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From garry@REDACTED Thu Mar 12 05:18:39 2015 From: garry@REDACTED (Garry Hodgson) Date: Thu, 12 Mar 2015 00:18:39 -0400 Subject: [erlang-questions] problems with cowboy hello world Message-ID: <5501139F.4000605@research.att.com> i'm trying to port a webmachine application to cowboy, with puzzling results so far. i've got all the plumbing set up, and my handlers get called. i actually need to use cowboy_rest_handler, but am trying first to get basic http working. so i copied the example from the User Guide: -module( hello_api ). -export( [ init/3, terminate/3 ] ). init( Transport, Req, Opts ) -> Reply = cowboy_req:reply( 200, [ { <<"content-type">>, <<"text/plain">> } ], <<"Hello world!">>, Req ), log:debug( "hello:init(): Req is ~p", [ Req ] ), { ok, Reply, Opts }. terminate( Reason, Req, State) -> log:debug( "terminating for ~p", [ Reason ] ), ok. and when i hit the server with: --> curl k2v/v0/hello -v * About to connect() to k2v port 80 (#0) * Trying 135.207.243.29... connected * Connected to k2v (135.207.243.29) port 80 (#0) > GET /v0/hello HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: k2v > Accept: */* > < HTTP/1.1 200 OK < connection: keep-alive < server: Cowboy < date: Thu, 12 Mar 2015 03:52:39 GMT < content-length: 12 < content-type: text/plain < * Connection #0 to host k2v left intact Hello world! * Closing connection #0 it works in that i get my response, but terminate() never gets called, and i see this error report in erlang shell (included debug to show the req): =INFO REPORT==== 11-Mar-2015::23:52:40 === {log,debug, "hello:init(): Req is {http_req,#Port<0.3094>,ranch_tcp,keepalive,<0.297.0>,\n <<\"GET\">>,'HTTP/1.1',\n {{135,207,243,29},36394},\n <<\"k2v\">>,undefined,80,<<\"/v0/hello\">>,\n undefined,<<>>,undefined,[],\n [{<<\"user-agent\">>,\n <<\"curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2\">>},\n {<<\"host\">>,<<\"k2v\">>},\n {<<\"accept\">>,<<\"*/*\">>}],\n [],undefined,[],waiting,<<>>,undefined,false,\n waiting,[],<<>>,undefined}", logpost@REDACTED} =ERROR REPORT==== 11-Mar-2015::23:52:40 === Ranch listener cowboy_http_server had connection process started with cowboy_protocol:start_link/4 at <0.297.0> exit with reason: {function_clause,[{lists,zip,[[transport,connection,pid,method,version,peer,host,host_info,port,path,path_info,qs,qs_vals,bindings,headers,p_headers,cookies,meta,body_state,buffer,multipart,resp_compress,resp_state,resp_headers,resp_body,onresponse],[]],[{file,"lists.erl"},{line,385}]},{lists,zip,2,[{file,"lists.erl"},{line,385}]},{cowboy_handler,handler_terminate,4,[{file,"src/cowboy_handler.erl"},{line,291}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,118}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,442}]}]} the error seems to be because cowboy_handler:handler_terminate() is calling cowboy_req:to_list(Req) in this catch clause: handler_terminate(Req, Handler, HandlerState, Reason) -> try Handler:terminate(Reason, cowboy_req:lock(Req), HandlerState) catch Class:Reason2 -> erlang:Class([ {reason, Reason2}, {mfa, {Handler, terminate, 3}}, {stacktrace, erlang:get_stacktrace()}, {req, cowboy_req:to_list(Req)}, {state, HandlerState}, {terminate_reason, Reason} ]) end. where cowboy_req:to_list(Req) is: to_list(Req) -> lists:zip(record_info(fields, http_req), tl(tuple_to_list(Req))). and that second expression yields []. So, am i doing something wrong here? Has the api changed? The documentation and examples don't seem to agree with the code, let alone whatever questions/tutorials/etc i find when searching online. I gather the api's are in flux ( init/3 vs. init/2 and rest_init/2, { upgrade, protocol, cowboy_rest } vs { cowboy_rest, Req, #state{} } ), so i'm not sure what code i should be running. i grabbed the latest using erlang.mk bootstrap just a few days ago. any suggestions would be greatly appreciated. thanks. -- Garry Hodgson AT&T Chief Security Office (CSO) "This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited." From kennethlakin@REDACTED Thu Mar 12 06:07:56 2015 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Wed, 11 Mar 2015 22:07:56 -0700 Subject: [erlang-questions] problems with cowboy hello world In-Reply-To: <5501139F.4000605@research.att.com> References: <5501139F.4000605@research.att.com> Message-ID: <55011F2C.6070209@gmail.com> On 03/11/2015 09:18 PM, Garry Hodgson wrote: > i'm trying to port a webmachine application to cowboy, > with puzzling results so far. i've got all the plumbing set > up, and my handlers get called. i actually need to use > cowboy_rest_handler, but am trying first to get basic http > working. so i copied the example from the User Guide: If you're using Cowboy 1.0.x, (as I am), then I learned that you can't actually make a response in init/3. (I got exactly the same stacktrace that you're reporting.) All work has to be done in handle/2. This *should* be a correct Cowboy 1.0.x Hello World: -module( hello_api ). -export([ init/3, handle/2, terminate/3 ]). handle(Req, State) -> {ok, Req2} = cowboy_req:reply(200, [ {<<"content-type">>, <<"text/plain">>} ], <<"Hello World!">>, Req), {ok, Req2, State}. init(_Type, Req, _Opts) -> {ok, Req, no_state}. terminate(_Reason, _Req, _State) -> ok. I can't speak to how you would do this with with Cowboy HEAD. (As an aside, I very much dislike how erlang.mk treats all warnings as errors. I'm much more pleased when using rebar as a build system.) From essen@REDACTED Thu Mar 12 09:51:09 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 12 Mar 2015 09:51:09 +0100 Subject: [erlang-questions] problems with cowboy hello world In-Reply-To: <5501139F.4000605@research.att.com> References: <5501139F.4000605@research.att.com> Message-ID: <5501537D.3090107@ninenines.eu> Hello, On 03/12/2015 05:18 AM, Garry Hodgson wrote: > -export( [ init/3, terminate/3 ] ). > > init( Transport, Req, Opts ) -> This is the Cowboy 1.0.x interface. > Reply = cowboy_req:reply( This is the upcoming Cowboy 2 interface. The 1.0.x cowboy_req:reply function returns {ok, Req}. This is what causes the error later on. Make sure you read the correct version of the docs. If it helps you can install the man pages of the version you're using with "make docs ; make install-docs" and then man COWBOY_MODULE will work. Enjoy! -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Thu Mar 12 09:57:47 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 12 Mar 2015 09:57:47 +0100 Subject: [erlang-questions] problems with cowboy hello world In-Reply-To: <55011F2C.6070209@gmail.com> References: <5501139F.4000605@research.att.com> <55011F2C.6070209@gmail.com> Message-ID: <5501550B.8070905@ninenines.eu> On 03/12/2015 06:07 AM, Kenneth Lakin wrote: > If you're using Cowboy 1.0.x, (as I am), then I learned that you can't > actually make a response in init/3. (I got exactly the same stacktrace > that you're reporting.) All work has to be done in handle/2. In 1.0.x you can reply in init/3, but you still have to have a handle/2 function. > This *should* be a correct Cowboy 1.0.x Hello World: > > -module( hello_api ). > -export([ init/3, handle/2, terminate/3 ]). > > handle(Req, State) -> > {ok, Req2} = cowboy_req:reply(200, [ > {<<"content-type">>, <<"text/plain">>} > ], <<"Hello World!">>, Req), > {ok, Req2, State}. > > init(_Type, Req, _Opts) -> > {ok, Req, no_state}. > > terminate(_Reason, _Req, _State) -> > ok. > > > I can't speak to how you would do this with with Cowboy HEAD. Just remove init/3, remove terminate/3 (it's become optional), rename handle/2 into init/2 and fix the return value of cowboy_req:reply to "Req". -module( hello_api ). -export([ init/2 ]). handle(Req, State) -> {ok, cowboy_req:reply(200, [{<<"content-type">>, <<"text/plain">>}], <<"Hello World!">>, Req), State}. > (As an aside, I very much dislike how erlang.mk treats all warnings as > errors. I'm much more pleased when using rebar as a build system.) It's just the default, you can easily change it. I would advise fixing those warnings instead, though. -- Lo?c Hoguin http://ninenines.eu From drormein@REDACTED Thu Mar 12 10:52:06 2015 From: drormein@REDACTED (Dror Mein) Date: Thu, 12 Mar 2015 09:52:06 +0000 (UTC) Subject: [erlang-questions] process suspended on bif_return_trap/1 Message-ID: <256051477.4585090.1426153926045.JavaMail.yahoo@mail.yahoo.com> hi all,I have a gen_server process who is suspended. it's stack trace has him currently trying to send a message with a bang.?my first question is why? why a process gets suspended? current function: erlang:bif_return_trap/1the destination process is ok.second question: how do you guard from a situation like this? Thanks,Dror -------------- next part -------------- An HTML attachment was scrubbed... URL: From andra.dinu@REDACTED Thu Mar 12 11:51:27 2015 From: andra.dinu@REDACTED (Andra Dinu) Date: Thu, 12 Mar 2015 10:51:27 +0000 Subject: [erlang-questions] Meet Erlang inventors Joe, Mike and Robert in Palo Alto on 24 March Message-ID: Hi all, Joe Armstrong, Mike Williams and Robert Virding will be at the Erlounge meetup in Palo Alto on 24 March. Each of them will give a 20 minutes talk, see their abstracts an more on the event on meetup: http://www.meetup.com/ErlangSF/events/220955245/ This is a free event but places are limited, please register early, and if you can not make it, free your place so those on the waiting list are given a chance. Best, Andra *Andra Dinu* Community & Social Largest Erlang event in the US: Erlang Factory SF Bay Area 26-27 March . Scholarships available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Thu Mar 12 13:18:48 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 13:18:48 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> Message-ID: actually, terminate _is_ called also after gs process crashes while executing. so the exceptions are: 1) gs is unconditionally terminated using exit(Child,kill). 2) VM crash, power down & other calamities From mononcqc@REDACTED Thu Mar 12 13:25:23 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 12 Mar 2015 08:25:23 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> Message-ID: <20150312122522.GC63925@ferdair.local> On 03/12, Imants Cekusins wrote: > actually, terminate _is_ called also after gs process crashes while executing. > > so the exceptions are: > 1) gs is unconditionally terminated using exit(Child,kill). > 2) VM crash, power down & other calamities Each behaviour callback is usually in a 'try ... catch', so programming errors within a behaviour would end up executing 'terminate' before the process exits (gen_event handlers are *removed* when that happens, but the process stays up). However, any link, not just an explicit call to exit/2, can end up killing the process without calling terminate/2. So if I link(OtherPid) and OtherPid dies without me trapping exits, the signal is never converted to a message and my process wil die. If the process is trapping exits, then only exit(Pid, Kill) will take the process down brutally, along with the other VM- or System-wide stuff you mentioned. Regards, Fred. From imantc@REDACTED Thu Mar 12 13:47:47 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 13:47:47 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: <20150312122522.GC63925@ferdair.local> References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> Message-ID: ok so it's about these 2 functions: A) erlang:link(C::pid()) B) erlang:process_flag(trap_exit, Trap::boolean()) if I understood correctly, if a gs G calls A and B(false) and C dies, G's terminate is not called? From garry@REDACTED Thu Mar 12 13:51:59 2015 From: garry@REDACTED (Garry Hodgson) Date: Thu, 12 Mar 2015 08:51:59 -0400 Subject: [erlang-questions] problems with cowboy hello world In-Reply-To: <55011F2C.6070209@gmail.com> References: <5501139F.4000605@research.att.com> <55011F2C.6070209@gmail.com> Message-ID: <55018BEF.40304@research.att.com> On 03/12/2015 01:07 AM, Kenneth Lakin wrote: > On 03/11/2015 09:18 PM, Garry Hodgson wrote: >> i'm trying to port a webmachine application to cowboy, >> with puzzling results so far. i've got all the plumbing set >> up, and my handlers get called. i actually need to use >> cowboy_rest_handler, but am trying first to get basic http >> working. so i copied the example from the User Guide: > If you're using Cowboy 1.0.x, (as I am), then I learned that you can't > actually make a response in init/3. (I got exactly the same stacktrace > that you're reporting.) All work has to be done in handle/2. > > This *should* be a correct Cowboy 1.0.x Hello World: indeed, that worked. thanks! -- Garry Hodgson AT&T Chief Security Office (CSO) "This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited." From mononcqc@REDACTED Thu Mar 12 13:59:28 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 12 Mar 2015 08:59:28 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> Message-ID: <20150312125928.GE63925@ferdair.local> On 03/12, Imants Cekusins wrote: > ok so it's about these 2 functions: > > A) erlang:link(C::pid()) > B) erlang:process_flag(trap_exit, Trap::boolean()) > > if I understood correctly, if a gs G calls A and B(false) and C dies, > G's terminate is not called? Right. Link signals are not converted to messages and the process dies without calling anything. From imantc@REDACTED Thu Mar 12 14:02:40 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 14:02:40 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> Message-ID: thank you Fred! sorry, another question: so gen_X:start is (among other things) a spawn with no link, no trapping and gen_X:start_link is spawn + link + trap exits? OTP are always started via either start or start_link, so a gs needs to spawn a non-OTP process, explicitly link to it and not trap exits to put its terminate at risk? From mononcqc@REDACTED Thu Mar 12 14:10:21 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 12 Mar 2015 09:10:21 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> Message-ID: <20150312131020.GG63925@ferdair.local> On 03/12, Imants Cekusins wrote: > thank you Fred! > > sorry, another question: > > so gen_X:start is (among other things) a spawn with no link, no trapping > and gen_X:start_link is spawn + link + trap exits? > - No behaviour traps exits automatically except supervisors. That's for you to decide. - gen_x:start has no link. they are not meant to be used in supervision trees (the doc mentions, for gen_server:start/3-4: "Creates a stand-alone gen_server process, i.e. a gen_server which is not part of a supervision tree and thus has no supervisor.") - start_link is spawn+link > OTP are always started via either start or start_link, > Whatever goes in a supervision tree *needs* start_link. > so a gs needs to spawn a non-OTP process, explicitly link to it and > not trap exits to put its terminate at risk? *Any* process that sets up a link will put it at risk if they don't trap exit, whether it's OTP or not. Links are a primitive of Erlang. OTP is a framework on top. No OTP behaviour traps exits by default (outside of 'supervisor'). Exit signals sent over links to processes will work the same everywhere, and will be altered the same way everywhere when trapping exits. Regards, Fred. From imantc@REDACTED Thu Mar 12 14:19:49 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 14:19:49 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: <20150312131020.GG63925@ferdair.local> References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> <20150312131020.GG63925@ferdair.local> Message-ID: so in the context of gs G, started in many possible ways: by a supervisor, by a standalone process, by an OTP process, via gs:start, or gs:start_link, the cases when G process ends yet its terminate is not called, are: 1) when another process calls exit(G, kill) (can only sup try this, or any parent, or any process even?); 2) when G spawns a non-OTP process C, links to it, does not trap exits, C dies, brings G down with it, terminate is not called; *) ? From imantc@REDACTED Thu Mar 12 14:32:53 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 14:32:53 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> <20150312131020.GG63925@ferdair.local> Message-ID: 3) G start_links OTP process O (not trapping exits in this case), O dies as above, brings G down with it - even though it is OTP-OTP link; *) ? From richard.youngkin@REDACTED Thu Mar 12 14:41:25 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Thu, 12 Mar 2015 07:41:25 -0600 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> <20150312131020.GG63925@ferdair.local> Message-ID: On Wed, Mar 11, 2015 at 5:20 PM, Fred Hebert wrote: > On 03/11, Youngkin, Rich wrote: > > "terminate/2 will also be called when its parent (the process that > spawned > > it) dies, if and only if the gen_server is trapping exits." > > > > [...] > > > > The Erlang documentation on Supervisors states "Note that all child > > processes implemented using the standard OTP behavior modules > automatically > > adhere to the shutdown protocol.". I'm having trouble reconciling these > > LYSE with the Erlang Supervisor docs. > > > > Thanks, > > Rich > > The references I found to the shutdown protocol is: > > > http://www.erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html#shutdown > > "The supervisor process sends an exit signal to the child process and > waits for acknowledgment. The child process should handle the > {'EXIT',ParentPid,shutdown} message and terminate with reason shutdown > if it traps exit signals." > > The last line here is important -- if it traps exit signals. This is in > agreement with what LYSE mentions. If you don't trap exit signals, you > can't get the signal, it just kills the process directly. > So let's say that: 1. Supervisor1 starts Supervisor2 and GenServerA in that order. 2. A Supervisor1 is given a child_spec with a simple_one_for_one restart strategy. 3. GenServerA implements a start/0 API function that results in calling supervisor:start_child(Supervisor1, [SomeArgs]) that creates ChildZ. 4. ChildZ's init/1 function does not trap_exits. 4. GenServerA also implements a stop/0 API function that results in calling supervisor:terminate_child(Supervisor1, ChildZPid) At step 4, will ChildZ:terminate/2 get called? Or does it have to trap_exit? If it's the latter AND ChildZ doesn't trap_exit then it seems as if ChildZ would have to implement handle_info('EXIT', ParentPid, shutdown) which could then call terminate/2? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Thu Mar 12 14:45:18 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 12 Mar 2015 09:45:18 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> <20150312131020.GG63925@ferdair.local> Message-ID: <20150312134517.GH63925@ferdair.local> On 03/12, Imants Cekusins wrote: > so in the context of gs G, started in many possible ways: by a > supervisor, by a standalone process, by an OTP process, via gs:start, > or gs:start_link, the cases when G process ends yet its terminate is > not called, are: > > 1) when another process calls exit(G, kill) (can only sup try this, or > any parent, or any process even?); > Any process can try it. trap_exit can also capture exit/2 calls made with any argument *but* 'kill'. I think most of the questions you ask come from not properly understanding the signals in Erlang, and how trapping exits affects them. I recommend reading possibly http://learnyousomeerlang.com/errors-and-processes for this. > 2) when G spawns a non-OTP process C, links to it, does not trap > exits, C dies, brings G down with it, terminate is not called; > That the process is OTP or not has *nothing* to do with signals and trapping exits. Those are *primitives* of Erlang, and again, OTP is a framework built on top of them. The true underlying question under all of these is "can a process know it receives a signal or is it being killed first". The answer is the process is always killed first if it's not trapping exits. If it's trapping exits, the signal is converted to an {'EXIT', Pid, Reason} message, *except* when the reason is 'kill'. A signal can be sent implicitly by a linked dying process, or by calling exit/2 on a process. From mononcqc@REDACTED Thu Mar 12 14:48:08 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 12 Mar 2015 09:48:08 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> <20150312131020.GG63925@ferdair.local> Message-ID: <20150312134807.GI63925@ferdair.local> On 03/12, Imants Cekusins wrote: > 3) G start_links OTP process O (not trapping exits in this case), O > dies as above, brings G down with it - even though it is OTP-OTP link; > OTP has nothing to do with it. Links and trapping are Erlang *primitives*. They operate below OTP. OTP can't do anything about them to change how they work. From mononcqc@REDACTED Thu Mar 12 14:57:27 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 12 Mar 2015 09:57:27 -0400 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> <20150312131020.GG63925@ferdair.local> Message-ID: <20150312135726.GJ63925@ferdair.local> On 03/12, Youngkin, Rich wrote: > So let's say that: > 1. Supervisor1 starts Supervisor2 and GenServerA in that order. Sup1 / \ Sup2 GenA > 2. A Supervisor1 is given a child_spec with a simple_one_for_one restart > strategy. That isn't possible because Sup2 and GenA are two different types. Maybe you meant: Sup1 | Sup2 | GenA Which I will assume from now on because otherwise it doesn't make sense. So Sup1 has a SOFO strategy over a supervisor 'Sup2', which itself has an undetermined child_spec to GenA. > 3. GenServerA implements a start/0 API function that results in calling > supervisor:start_child(Supervisor1, [SomeArgs]) that creates ChildZ. Sup1 | \ Sup2 Sup2FromGenA (ChildZ) | | GenA GenZ This is the only thing that makes sense for this, because the SOFO strategy keeps GenZ from being a child of Sup1. > 4. ChildZ's init/1 function does not trap_exits. In this case I'll assume you mean 'GenZ' ? But it breaks your assumptions of simple_one_for_one supervisors. So let's back track and say you meant 'one_for_one'. Then we can have: Sup1-----, / \ | Sup2 GenA ChildZ Because we can have multiple strategies. > 4. GenServerA also implements a stop/0 API function that results in > calling supervisor:terminate_child(Supervisor1, ChildZPid) > Going with the last graph then okay, that works. Any of the prior ones don't. > At step 4, will ChildZ:terminate/2 get called? Or does it have to No it will not get called because supervisors shut down their children with exit signals. If ChildZ is not trapping exit, the exit signal will not be controlled and it will kill the process. > trap_exit? If it's the latter AND ChildZ doesn't trap_exit then it seems as > if ChildZ would have to implement handle_info('EXIT', ParentPid, shutdown) > which could then call terminate/2? > THe process can only have handle_info({'EXIT', NonParentPid, shutdown}, State) if, and only if it traps exits. Actually you will *never* see ParentPid show up, because signals from the parent process are filtered, handled, and hidden by the OTP behaviour themselves. Only trapped signals from non-parent processes are bubbled up and shown to the user via the handle_info/2 function. Regards, Fred. > Thanks, > Rich From imantc@REDACTED Thu Mar 12 15:07:21 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 15:07:21 +0100 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: <20150312134807.GI63925@ferdair.local> References: <20150312001108.GB1523@ferdmbp.local> <20150312122522.GC63925@ferdair.local> <20150312131020.GG63925@ferdair.local> <20150312134807.GI63925@ferdair.local> Message-ID: so, to ensure gs terminate is called, otp:start_link | erlang:link should be followed by erlang:process_flag(trap_exit, true) can we say that? > most of the questions you ask come from not properly understanding the signals in Erlang, and how trapping exits affects them. I recommend reading possibly http://learnyousomeerlang.com/errors-and-processes for this. well you see I link only from supervisors via otp:start_link, spawn non-otp stuff and otp:start otp children from non-sups, relying on timeouts to tell that something went wrong. crashes do not really cause havoc in this scheme so I did not pay much attention to linking. I assumed that OTP links traps exits by default. Thank you for clarifying this! Thank you very much Fred. From garry@REDACTED Thu Mar 12 16:51:17 2015 From: garry@REDACTED (Garry Hodgson) Date: Thu, 12 Mar 2015 11:51:17 -0400 Subject: [erlang-questions] problems with cowboy hello world In-Reply-To: <5501537D.3090107@ninenines.eu> References: <5501139F.4000605@research.att.com> <5501537D.3090107@ninenines.eu> Message-ID: <5501B5F5.4000308@research.att.com> On 3/12/15 4:51 AM, Lo?c Hoguin wrote: > > Make sure you read the correct version of the docs. If it helps you > can install the man pages of the version you're using with "make docs > ; make install-docs" and then man COWBOY_MODULE will work. ah, that helps a lot. i assume that for now i should be using 1.0.x? i'm using: make -f erlang.mk bootstrap bootstrap-rel add "DEPS=cowboy to Makefile make deps as shown in the getting started guide. is there a way to ensure that i get a specific branch/version/commit using that? thanks for your help. From essen@REDACTED Thu Mar 12 16:54:39 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 12 Mar 2015 16:54:39 +0100 Subject: [erlang-questions] problems with cowboy hello world In-Reply-To: <5501B5F5.4000308@research.att.com> References: <5501139F.4000605@research.att.com> <5501537D.3090107@ninenines.eu> <5501B5F5.4000308@research.att.com> Message-ID: <5501B6BF.4000403@ninenines.eu> On 03/12/2015 04:51 PM, Garry Hodgson wrote: > On 3/12/15 4:51 AM, Lo?c Hoguin wrote: >> >> Make sure you read the correct version of the docs. If it helps you >> can install the man pages of the version you're using with "make docs >> ; make install-docs" and then man COWBOY_MODULE will work. > ah, that helps a lot. i assume that for now i should be using 1.0.x? > > i'm using: > make -f erlang.mk bootstrap bootstrap-rel > add "DEPS=cowboy to Makefile > make deps That gets you 1.0.x. > as shown in the getting started guide. is there a way to ensure that > i get a specific branch/version/commit using that? Sure, add a dep_cowboy line like dep_cowboy = git https://github.com/ninenines.cowboy 1.2.3 (Note there is no such thing as 1.2.3 version; you should replace it with the tag/branch/commit you want.) -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Thu Mar 12 19:49:46 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 12 Mar 2015 19:49:46 +0100 Subject: [erlang-questions] process suspended on bif_return_trap/1 In-Reply-To: <256051477.4585090.1426153926045.JavaMail.yahoo@mail.yahoo.com> References: <256051477.4585090.1426153926045.JavaMail.yahoo@mail.yahoo.com> Message-ID: The bif_return_trap/1 is a trampoline function used by bifs that suspend in order to graft them onto the normal interpreter later on. It's purpose is to make the BIF look like a normal function. Processes might get suspended on a send for two reasons: * The process you are looking for is in another castle (read: on a foreign node). If the TCP buffer for the distribution protocol is full the process gets suspend until there is room. * The port you are sending to is currently busy. What this means depends on the type of port, but usually this is a full buffer of some kind as well. On Thu, Mar 12, 2015 at 10:52 AM, Dror Mein wrote: > hi all, > I have a gen_server process who is suspended. it's stack trace has him > currently trying to send a message with a bang. > my first question is why? why a process gets suspended? current function: > erlang:bif_return_trap/1 > the destination process is ok. > second question: how do you guard from a situation like this? > > Thanks, > Dror > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From garry@REDACTED Thu Mar 12 20:38:26 2015 From: garry@REDACTED (Garry Hodgson) Date: Thu, 12 Mar 2015 15:38:26 -0400 Subject: [erlang-questions] problems with cowboy hello world In-Reply-To: <5501B6BF.4000403@ninenines.eu> References: <5501139F.4000605@research.att.com> <5501537D.3090107@ninenines.eu> <5501B5F5.4000308@research.att.com> <5501B6BF.4000403@ninenines.eu> Message-ID: <5501EB32.4030005@research.att.com> On 03/12/2015 11:54 AM, Lo?c Hoguin wrote: > >> as shown in the getting started guide. is there a way to ensure that >> i get a specific branch/version/commit using that? > > Sure, add a dep_cowboy line like > > dep_cowboy = git https://github.com/ninenines.cowboy 1.2.3 > > (Note there is no such thing as 1.2.3 version; you should replace it > with the tag/branch/commit you want.) prefect. thanks. -- Garry Hodgson AT&T Chief Security Office (CSO) "This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited." From n.oxyde@REDACTED Thu Mar 12 22:32:00 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Mar 2015 22:32:00 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> Message-ID: <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Le 18 f?vr. 2015 ? 01:47, Richard A. O'Keefe a ?crit : >> by "static" I meant immutable. yes, "static" can mean various things. >> in this case it is a misnomer. > > "Immutable" is not one of the things "static" can mean. Indeed, it isn't. https://github.com/erlang/otp/pull/643 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Thu Mar 12 22:59:21 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 22:59:21 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: *Computing* (Of a process or variable ) notable to be changed during a set period,for example while a program is running http://www.oxforddictionaries.com/definition/english/static -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Thu Mar 12 23:09:05 2015 From: radek@REDACTED (Rad Gruchalski) Date: Thu, 12 Mar 2015 23:09:05 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: <28A6638C9BAA48719EB72C2E76C3DC2A@gruchalski.com> Indeed, but more common usage of static in computer programming relates to ?object property/method? instead of ?class?. In Erlang, one could argue that mod:something(), where mod is indeed -module(mod), is static. But in general term, static is not equal to immutable. Take a look at Java: class Whatever { public static String meh = ?meh?; } You can change the value of meh by: Whatever.meh = ?meh meh?; while immutable would be: public static final String immutableMeh = ?meh?; You can?t change the value of this one. There is a difference. Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) +4917685656526 Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Thursday, 12 March 2015 at 22:59, Imants Cekusins wrote: > Computing (Of a process (http://www.oxforddictionaries.com/definition/english/process#process__3) or variable (http://www.oxforddictionaries.com/definition/english/variable#variable__15)) notable (http://www.oxforddictionaries.com/definition/english/able#able__3) to be changed (http://www.oxforddictionaries.com/definition/english/change#change__3) during a set period,for example (http://www.oxforddictionaries.com/definition/english/example#example__15) while a program is running > http://www.oxforddictionaries.com/definition/english/static > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Thu Mar 12 23:10:13 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 23:10:13 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: https://github.com/erlang/otp/pull/643 Well done, Anthony!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Mar 12 23:10:33 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Mar 2015 23:10:33 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: Le 12 mars 2015 ? 22:59, Imants Cekusins a ?crit : > Computing (Of a process or variable) not able to be changed during a set period,for example while a program is running > > http://www.oxforddictionaries.com/definition/english/static > I myself also often use the Oxford dictionary to learn more about French cheese. Name one language where 'static' refers to immutability and I will name three others that don't. From imantc@REDACTED Thu Mar 12 23:23:01 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 23:23:01 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: more common usage of static in computer programming relates to "object property/method" instead of "class". Radek, I use words to explain my thoughts. People often mean different things by the same word and vice versa. It is good to understand someone, even if we both use wrong words - as long as we both try to understand each other. Choosing the right words is important. However the key purpose of constructive communication is exchange of ideas, understanding. Let us focus on what the other person is trying to convey! -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Thu Mar 12 23:25:25 2015 From: radek@REDACTED (Rad Gruchalski) Date: Thu, 12 Mar 2015 23:25:25 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: And as such, it is important to declare common ground. Otherwise misconceptions occur. As such - ?immutable" is not the same as ?static", as presented in the example given earlier. Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Thursday, 12 March 2015 at 23:23, Imants Cekusins wrote: > more common usage of static in computer programming relates to ?object property/method? instead of ?class?. > Radek, I use words to explain my thoughts. People often mean different things by the same word and vice versa. > It is good to understand someone, even if we both use wrong words - as long as we both try to understand each other. > Choosing the right words is important. However the key purpose of constructive communication is exchange of ideas, understanding. > Let us focus on what the other person is trying to convey! > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.youngkin@REDACTED Thu Mar 12 23:31:19 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Thu, 12 Mar 2015 16:31:19 -0600 Subject: [erlang-questions] Binary data hiding sasl log entries? In-Reply-To: References: Message-ID: I have some more information, and questions, regarding this. First, the number of "^@" characters is not in the thousands, it's in the millions and represents most of the size of the file. This plays into the second item. We're using logrotate and there seems to be a possible problem with that (this is a fairly old post). https://groups.google.com/forum/#!topic/comp.unix.solaris/Zc7ysjMGprQ When we turned off logrotate for the sasl log the problem disappeared. So this does indeed look like a bad interaction between logrotate and and the process writing to the sasl log. Given that there are sasl settings for *error_logger_mf_maxbytes and **error_logger_mf_maxfiles, *I'm wondering if this is a known issue with using logrotate with the sasl log, and/or if anyone else has run into it? http://www.erlang.org/doc/man/sasl_app.html For now, we're going to switch from logrotate to the sasl log config settings. Thanks, Rich Hi all, I was wondering if anyone has seen binary data in a sasl log and > what might > be causing it. I'm seeing thousands and thousands of "^@" characters. In > addition, I'm not seeing expected startup messages and I'm wondering if > this info has been obscured by the binary data. I only see this occur at > the beginning of a sasl log. I'm using R15B03. Thanks, > Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Thu Mar 12 23:43:47 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 23:43:47 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: Why some programmers pay much attention to what the others say about programming, how they write their code, try to convince, change their mind? Let's say, a program is written by someone. For various reasons, we may choose to use it or not. But isn't the key criteria: does it work for us? I use so much software of which I have no slightest idea what the code looks like. Yet it works! Why would I try to convince someone how to write their code? I can see this is a popular sport. Yet I must be missing something. What's the thrill? Oh yeah, and why are there so many different programming languages? Can there be just one or two? ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Thu Mar 12 23:46:23 2015 From: radek@REDACTED (Radoslaw Gruchalski) Date: Thu, 12 Mar 2015 22:46:23 +0000 (UTC) Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: Sorry, I thought the discussion was "immutable" vs "static". Sent from Outlook On Thu, Mar 12, 2015 at 3:43 PM -0700, "Imants Cekusins" wrote: Why some programmers pay much attention to what the others say about programming, how they write their code, try to convince, change their mind? Let's say, a program is written by someone. For various reasons, we may choose to use it or not. But isn't the key criteria: does it work for us? I use so much software of which I have no slightest idea what the code looks like. Yet it works! Why would I try to convince someone how to write their code? I can see this is a popular sport. Yet I must be missing something. What's the thrill? Oh yeah, and why are there so many different programming languages? Can there be just one or two? ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Mar 12 23:50:56 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Mar 2015 23:50:56 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: Le 12 mars 2015 ? 23:43, Imants Cekusins a ?crit : > Why some programmers pay much attention to what the others say about programming, how they write their code, try to convince, change their mind? > > Let's say, a program is written by someone. For various reasons, we may choose to use it or not. But isn't the key criteria: does it work for us? > > I use so much software of which I have no slightest idea what the code looks like. Yet it works! > > Why would I try to convince someone how to write their code? I can see this is a popular sport. Yet I must be missing something. What's the thrill? > > Oh yeah, and why are there so many different programming languages? Can there be just one or two? > > ;) I didn't try to convince you about how you should write their code, but that you should use the right words to designate the ideas you want to refer to, otherwise no communication is possible. That a dictionary not at all specific to the domain of computer science provides you with a definition completely at odds with common usage in literature and practice is irrelevant. We pay attention to the words you use because you came to us with an idea dubious in the context of Erlang, initially with words that were inappropriate to describe what you were talking about, adding to the confusion. There are so many different programming languages because there are so many different ways to solve a given problem, accompanied with many words to document them, some better than others. From imantc@REDACTED Thu Mar 12 23:54:14 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 23:54:14 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: > I thought the discussion was "immutable" vs "static". The topic could just as well be called: " all the wrong things others say." :-P -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Thu Mar 12 23:58:51 2015 From: imantc@REDACTED (Imants Cekusins) Date: Thu, 12 Mar 2015 23:58:51 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: > you should use the right words to designate the ideas you want to refer to, otherwise no communication is possible. Anthony, I try to communicate and understand even if we clearly do not speak the same language, are very different people. It can be a lot of fun. The key thing is: both persons should try. Then it simply works. It's a kind of magic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Mar 13 00:05:20 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Mar 2015 00:05:20 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: <4983DE48-BC0F-4CB7-8287-8102ED46AFB3@gmail.com> Le 12 mars 2015 ? 23:58, Imants Cekusins a ?crit : > It can be a lot of fun. The key thing is: both persons should try. Then it simply works. > > It's a kind of magic. Well, I just briefly resurrected that topic with a humorous tone because I remembered it when fixing that static bug. You are the one insisting about your own definition of static. Why not just admit that static never refers (at least not nearly as much as other unrelated things) to immutability in computer science, savour the horror of that bug born from C's insanity and call it a day? From radek@REDACTED Fri Mar 13 00:06:04 2015 From: radek@REDACTED (Radoslaw Gruchalski) Date: Thu, 12 Mar 2015 23:06:04 +0000 (UTC) Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: Imants, Not trying to offend, are you a politician? Sent from Outlook On Thu, Mar 12, 2015 at 3:58 PM -0700, "Imants Cekusins" wrote: > you should use the right words to designate the ideas you want to refer to, otherwise no communication is possible. Anthony, I try to communicate and understand even if we clearly do not speak the same language, are very different people. It can be a lot of fun. The key thing is: both persons should try. Then it simply works. It's a kind of magic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Fri Mar 13 00:23:12 2015 From: imantc@REDACTED (Imants Cekusins) Date: Fri, 13 Mar 2015 00:23:12 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: <4983DE48-BC0F-4CB7-8287-8102ED46AFB3@gmail.com> References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> <4983DE48-BC0F-4CB7-8287-8102ED46AFB3@gmail.com> Message-ID: Anthony, about "that bug" I understood nothing but I believe that you fixed it. Well done! I thought your original message was humorous. Here is the story with the dictionary: I started to wonder why I'd used this word and out of curiosity I looked it up. I was happy to see that even though possibly incorrect in this context, general definition does not imply something completely opposite. I quoted this definition in humorous mood, too. I did not add any comments, maybe I should have. Yes, let's wrap it up for today. It's good thing you fixed that bug, indeed. No doubt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Fri Mar 13 00:26:03 2015 From: imantc@REDACTED (Imants Cekusins) Date: Fri, 13 Mar 2015 00:26:03 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: > are you a politician? What are you - a cop? :-P What office should I run for? ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Fri Mar 13 00:29:21 2015 From: radek@REDACTED (Radoslaw Gruchalski) Date: Thu, 12 Mar 2015 23:29:21 +0000 (UTC) Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: Top secret! Disclose all your datas! ;)I applied for ministry of silly wals, wanna join? Sent from Outlook On Thu, Mar 12, 2015 at 4:26 PM -0700, "Imants Cekusins" wrote: > are you a politician? What are you - a cop? :-P What office should I run for? ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Mar 13 05:26:10 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 13 Mar 2015 17:26:10 +1300 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: <28A6638C9BAA48719EB72C2E76C3DC2A@gruchalski.com> References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> <28A6638C9BAA48719EB72C2E76C3DC2A@gruchalski.com> Message-ID: The word 'static' came into languages like Java and C# from C++. C++ got it from C. C got it from BCPL. BCPL got it from PL/I. I don't know where PL/I got it. Enterprise PL/I for z/OS and OS/390 Language Reference Version 3 Release 2.0 SC27-1460-02 is my current reference, but this keyword goes back to about 1965. The distinction in PL/I is between STATIC storage is allocated when the program is loaded and not freed until the program finishes. AUTOMATIC storage is allocated upon each entry to the block that contains the declaration and released when the block is exited. CONTROLLED a controlled variable is basically a stack of hidden pointers. Storage is allocated by the ALLOCATE statement and released by the FREE statement; the current allocation hides earlier ones. BASED allocation is manual; when you use such a variable you are actually going through a pointer or AREA that you specified. See page 239ff of the reference above. Now static suggests 'not moving or changing'; what is not moving or changing here is the *address* of a variable. That is, since about 1965, 'static' in computing has meant "having an unchanging address". Modern PL/I does have a way to say that the value associated with a variable cannot be changed: declare Some_Identifier value (Some_Restricted_Expression); BCPL also had a way to declare identifiers with unchanging values; the keyword was MANIFEST, not static. None of this has anything to do with OO. (Fortran uses 'SAVE' for static and 'PARAMETER' for constant.) The COBOL 08 draft standard said 4.176 static data: Data that has its last-used state when a runtime element is re-entered. 8.6.3 Automatic, initial, and static internal items Each internal item has one of the three persistence attributes: automatic, initial, or static. and the senses of 'automatic' and 'static' here are close to PL/I. (But the sense of 'static' is quite different from Java.) From ok@REDACTED Fri Mar 13 05:37:36 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 13 Mar 2015 17:37:36 +1300 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: <1A67065C-6053-40B0-B946-2D94F97C479C@cs.otago.ac.nz> On 13/03/2015, at 10:59 am, Imants Cekusins wrote: > Computing (Of a process or variable) notable to be changed during a set period,for example while a program is running > > http://www.oxforddictionaries.com/definition/english/static > Guess what? Dictionaries contain errors. If you trouble to look at the example sentences for that entry, NOT ONE OF THEM IS TALKING ABOUT AN IMMUTABLE VARIABLE. All of them are clearly using 'static' in the C|BCPL|PL/I sense of unchanging *address*, not unchanging *contents*. Sense 3, about electric charge, is clearly wrong. Whether a charge is static or not depends on whether it is *moving* or not, not whether it is on a non-conductive body. It is quite commonplace to have a static charge on a conductive object. With my comments in brackets, the OED dictionary entry has c. Computing. That cannot be changed while a program or operating system is running; that must be specified, changed, or performed in advance of run time. Cf. dynamic adj. and n. Additions. [What makes a 'static variable' static is that the ADDRESS of the variable cannot be changed.] 1957 Proc. 11th Western Joint Computer Conf. 44/1 The 60-word block of core storage serves as a static buffer for information transferred between the computer and tape. [This clearly refers to an *UNMOVING* block of storage whose *CONTENTS* change very frequently.] 1973 Ann. Rev. Automatic Programming 7 103 We call this pointer the static pointer, the pointer to the calling block being the dynamic pointer. [For a long time we've called these static and dynamic LINKS, not static and dynamic POINTERS. A static link in a procedure's frame refers to the frame of the procedure that statically encloses the first one; the dynamic link refers to the frame of the caller. This has nothing to do with immutable variables.] 2006 R. Hyde Write Great Code II. viii. 201 Because the lifetime of a static variable matches that of the program, static variables consume memory the entire time the program is running. [And this one is precisely the C|BCPL|PL/I sense of a statically *allocated* variable whose *contents* may be freely changed.] From ok@REDACTED Fri Mar 13 05:39:18 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 13 Mar 2015 17:39:18 +1300 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: <88D34725-9478-4E28-AE8B-0D6B614D841A@cs.otago.ac.nz> On 13/03/2015, at 11:23 am, Imants Cekusins wrote: > more common usage of static in computer programming relates to ?object property/method? instead of ?class?. > > Radek, I use words to explain my thoughts. People often mean different things by the same word and vice versa. > > It is good to understand someone, even if we both use wrong words - as long as we both try to understand each other. > > Choosing the right words is important. However the key purpose of constructive communication is exchange of ideas, understanding. Right! And if we claim Humpty-Dumpty's privilege of using words to mean whatever we want them to instead of what other people expect them to mean, well, there's glory for you. From me@REDACTED Thu Mar 12 23:45:12 2015 From: me@REDACTED (Leandro Ostera) Date: Thu, 12 Mar 2015 19:45:12 -0300 Subject: [erlang-questions] NFI's and running multiple VM's Message-ID: Hello there guys, I've been shoving tons of Erlang content down my information-ingestion-system for the past few days, and I'll continue to do so in the next few weeks while I embark on this strange land. Anywho, I wanted to say hi and thank everyone who either has spoken at (or is planning to) that appears on the Erlang Solutions vimeo videos ?which has been my main source of getting into this besides Fred Hebert's book (got the rocking paperback edition)? or put up an article online somewhere. Kudos for the great material. And for a beginners question... I was trying to use a quite old erlang wrapper around libspotify , which seems to be defining a bunch of NIFs, to make an audio streaming server that would keep N web-based clients playing the same audio at (give or take milliseconds) the same time. The problem is that according to one of the source files , it'd only be able to have one open Spotify session per VM, which of course didn't sound too exciting. Is this a limitation of building the wrapper as a set of NIFs? What'd be a way of not having these sessions attached to the VM but instead maybe to a particular process that would take care of buffering/streaming the audio? If the session was to stick to the VM, what'd be a practical way of making this support 100 sessions (or upwards)? I hope these questions make sense. Frankly, I've been postponing this day for the past 2 years or so. Hopefully it's the right time now :) Thanks and cheers! Leandro -- Leandro Ostera Github | LinkedIn | Facebook | @leostera -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Mar 13 06:25:39 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 13 Mar 2015 18:25:39 +1300 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: <6E84EF03-3F7E-426D-A930-B4B956A8EB92@cs.otago.ac.nz> On 13/03/2015, at 11:43 am, Imants Cekusins wrote: > Why some programmers pay much attention to what the others say about programming, how they write their code, try to convince, change their mind? Because if you *talk* wrong about a program, you'll *write* it wrong. > > Let's say, a program is written by someone. For various reasons, we may choose to use it or not. But isn't the key criteria: does it work for us? "Criteria" is plural. And no, the question is not "does it work". Practically no software can be relied on to work. The question is "can it be fixed". And if the programmer gibbered like a maniac speaking a private language, the answer is "probably not." > > I use so much software of which I have no slightest idea what the code looks like. Yet it works! It must be nice to live on your planet. How do I get there? This week, for example, I had a large (vertices and edges) graph that I wanted to display. So I turned to a program that I have mostly been able to use in the past. There are some painful user interface issues, but I can work around them by killing the program and restarting. Except that I now have Java 1.8 on my machine, and this program only works in Java 1.6. So there are sources. The web page explains how to build the program from sources using NetBeans. No problem. I have NetBeans. It turns out that they switch from NetBeans projects to Maven. I didn't have Maven. So I installed Maven. And the attempt to build the program I wanted to use failed miserably, and I have no idea why. Installing Java 1.6 on the machine didn't let the program work, as people on the net said it would. Although Java 1.6 is _there_, the program insists on using Java 1.8 and failing. THIS HAPPENS TO ME ALL THE TIME. Just yesterday, I had to pay quite a large bill at a major bank. One of their computer "systems" WILL accept apostrophes in names and one of them WON'T. Why is this *still* a continuing annoyance 50 years after banks here started using computers? Today I bought materials for lunch at a nearby supermarket. I have a debit card with a chip and a stripe. I inserted the card for the chip and it said to swipe it. So I swiped the card and the EFTPOS system said to insert it. So I inserted it and the system said to swipe it. When it timed out and reset, the machine read the card with no trouble at all. This is *COMMONPLACE*. I'm typing this in "Mail" version 7.3 (1878.6) on a desktop Mac running OS X version 10.9.5. The "Search" facility is totally non-functional and has been since I got this version of the software. Nobody here knows how to fix it. (You can go through the motions of searching, but there is no known set of conditions under which it will ever find anything, even the message you are looking at.) I am reduced to running an antique WebMail system in a web browser (I do not know if SquirrelMail is its real name or just what people call it) in order to search *and* Mail in order to have something nearly usable for typing into. Or take the iPad my department has loaned to me. When I upgraded to iOS 7, it forgot that it had a loudspeaker. That took some fixing. A planet where "Yet it works!" was even *close* to true would be a truly amazing place to visit. > > Why would I try to convince someone how to write their code? Because most code is HORRIBLE. And most of the remainder is BLOODY HORRIBLE. Because somehow you are going to end up paying for it to be fixed. I left industry for academia because I was really sick of commercial programs that didn't work, and wanted to try to help educate programmers to do better. The forces working against this are so strong that I'm not satisfied that I've achieved much. > I can see this is a popular sport. Yet I must be missing something. What's the thrill? There is no thrill. There is bitter anguish borne of long experience. There are people desperately trying to avoid being harmed AGAIN. > > Oh yeah, and why are there so many different programming languages? Can there be just one or two? We (as in the industry as a whole, and individuals who've lived through enough of it) have tried that. It didn't work. Lisp was a shining example of the international Lisp community getting together to define a common dialect. Even the InterLisp people, with an ugly but extremely *useful* dialect, co-operated, despite it meaning they had to write a whole new compiler. What was the result of Common Lisp coming out? Two rival standards: EULisp and ISLisp. (Don't bother looking them up; you won't find anything worth using.) Before that, PL/I was supposed to be the One Ring to rule them all: it merged COBOL, Algol, and Fortran, with a bit of list manipulation thrown in. (Although for some reason they thought pointers were where the type system should completely give up.) More recently, we saw Ada as the one all-purpose programming language. There's a lot to like in Ada. It is so clever and powerful that the only bugs in your program are the ones in the compiler. (Joke.) Honestly, I like Ada. But it would be an incredibly bad replacement for the UNIX shell... Of course there are social factors. Judging from your name, I suspect that you probably don't speak Maori. Are you interested in abandoning your native language and switching to Maori? How about Hindi? But there are also technical factors. Amongst other things, programming languages are designed by human beings, WHO MAKE MISTAKES. People often make mistakes because THEY TAKE TO THEMSELVES USING SLOPPY TERMINOLOGY. As a case in point, Coral 66, which is still supported, was a nice little language in which the designers somehow managed to tangle up the concepts "has an initial value" and "is statically allocated" as if they were the same thing. And they perpetuated the dangling else and the "'while' is only available as part of a 'for' loop" design botches long after the Algol community had realised that these were mistakes. (Well, how can we blame Coral 66's designers for keeping the dangling else when Java's and JavaScript's designers perpetuated the same bungle despite decades more experience that this was stupid? Because people figured out almost immediately after Algol 60 was published that it was a blunder, _that's_ how we can blame them.) But another technical issue is that programming languages serve different needs. There's a whole area of "domain specific languages" (going back to the 60s when they were called "problem oriented languages") based on the idea that a special-purpose language can make it EASIER to say what you DO want and HARDER to say what you DON'T want. I've just finished the first draft implementation of a little language for generating configuration files in JSON. It's the first time I've even considered a language that does not support recursion, but a key point of the design is that any script in this language MUST terminate. (It also cannot have any effect on the file system other than updating last-read timestamps.) I wouldn't tolerate this in a general purpose language, but for this special purpose, it's just right. I will admit to fairly serious annoyance that having installed Ant and Maven on my machine, the next JVM program I was interested in using turned out to require Leiningen. A couple of hours ago I was talking to a student who's doing something cool with an Android tablet -- not Erlang-related, sorry -- and I told him that he should make sure that anyone who has an Android SDK for C++ should be able to install and even build program without anything extra. From ali.sabil@REDACTED Fri Mar 13 11:20:42 2015 From: ali.sabil@REDACTED (Ali Sabil) Date: Fri, 13 Mar 2015 11:20:42 +0100 Subject: [erlang-questions] Why does Dialyzer crash on this map? In-Reply-To: <4B9AEB77-A709-4D97-8EF2-8FE1AF5A4071@llaisdy.com> References: <54749C90.6000602@llaisdy.com> <5474BA4C.4030706@llaisdy.com> <547716F8.7010208@llaisdy.com> <4B9AEB77-A709-4D97-8EF2-8FE1AF5A4071@llaisdy.com> Message-ID: Has this been solved for 17.4? I am getting the same crash on a quite large code base using 17.4.1 Thanks, Ali On Thu, Nov 27, 2014 at 10:05 PM, Ivan Uemlianin wrote: > Dear Bj?rn-Egil > > Thanks very much for your work and for reporting back. It looks like good > news (for me and for 18 at least). > > Best wishes > > Ivan > > -- > festina lente > > > On 27 Nov 2014, at 20:52, Bj?rn-Egil Dahlberg < > wallentin.dahlberg@REDACTED> wrote: > > Looks like the regression was introduced in > 'hb/dialyzer/fix_recognition_of_records/OTP-11935' > (805f9c89fc01220bc1bb0f27e1b68fd4eca688ba) included from OTP 17.1 > > This becomes a none-issue in the master branch (for 18) since variables > are allowed as keys there but it needs to be solved for the 17 track. > > > 2014-11-27 21:13 GMT+01:00 Bj?rn-Egil Dahlberg < > wallentin.dahlberg@REDACTED>: > >> I managed to reproduce your errors on dt.erl and dt2.erl using OTP-17.3.3 >> tag. >> >> Seems like I've missed something in dataflow .. looks like a clause >> missing for the map type. >> I'm not well versed in dialyzer. Hopefully I can do a fix for it for 17.4. >> >> There are a bit more stuff going on here too. When dialyzer uses the >> erlang compiler to compile to core >> it does not coalesce things to literals but keeps them abstract instead >> .. >> Compound keys such as [1,2,3] and {4,5,6} will thus become non-literals >> (variables) and such keys are not allowed in maps. >> >> I need to ponder that a bit before I try to solve it. >> >> // Bj?rn-Egil >> >> 2014-11-27 13:20 GMT+01:00 Ivan Uemlianin : >> >>> Dear Dave >>> >>> Thanks for your help. Here are some more details: >>> >>> >>> *** OS: FreeBSD 10.0-RELEASE >>> >>> $ uname -a >>> FreeBSD simba 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 >>> 22:34:59 UTC 2014 root@REDACTED:/usr/obj/usr/src/sys/GENERIC >>> amd64 >>> >>> Upgrading to 10.1 is on my todo list. >>> >>> >>> *** Erlang version now 17.3_3,3 >>> >>> $ pkg info erlang >>> erlang-17.3_1,3 >>> ... >>> $ sudo pkg upgrade >>> ... >>> >>> $ pkg info erlang >>> erlang-17.3_3,3 >>> ... >>> >>> >>> *** Errors persist >>> >>> Upgrading erlang has not changed behaviour. >>> >>> A couple more observations: >>> >>> 1. Running dialyzer on the module dt below gets the error as noted >>> previously. However, if I uncomment the '%% ok' line, dialyzer will >>> process the module with no problems. >>> >>> -module(dt). >>> -export([get_map/0]). >>> >>> -spec get_map() -> map(). >>> get_map() -> >>> #{labels => [one, two], >>> number => 27, >>> %% [1,2,3] => wer, %% ok >>> kvok => #{ >>> a => qwe, >>> 2 => asd, >>> [1,2,3] => wer, %% bad >>> {4,5,6} => sdf, %% bad >>> "abc" => zxc >>> } >>> }. >>> >>> $ dialyzer dt.erl >>> Checking whether the PLT /home/ivan/.dialyzer_plt is up-to-date... >>> yes >>> Proceeding with analysis... >>> =ERROR REPORT==== 27-Nov-2014::12:17:02 === >>> Error in process <0.45.0> with exit value: >>> {{case_clause,map},[{dialyzer_dataflow,find_terminals,1,[{ >>> file,"dialyzer_dataflow.erl"},{line,3451}]},{dialyzer_ >>> dataflow,find_terminals_list,3,[{file,"dialyzer_dataflow. >>> erl"},{line,3504}]},{dialyzer_dataflow,classify_returns... >>> >>> >>> dialyzer: Analysis failed with error: >>> {{case_clause,map}, >>> [{dialyzer_dataflow,find_terminals,1, >>> [{file,"dialyzer_dataflow.erl"},{line,3451}]}, >>> {dialyzer_dataflow,find_terminals_list,3, >>> [{file,"dialyzer_dataflow.erl"},{line,3504}]}, >>> {dialyzer_dataflow,classify_returns,1, >>> [{file,"dialyzer_dataflow.erl"},{line,3443}]}, >>> {dialyzer_dataflow,'-state__get_warnings/2-fun-0-',7, >>> [{file,"dialyzer_dataflow.erl"},{line,2908}]}, >>> {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, >>> {dialyzer_dataflow,state__get_warnings,2, >>> [{file,"dialyzer_dataflow.erl"},{line,2934}]}, >>> {dialyzer_dataflow,get_warnings,5, >>> [{file,"dialyzer_dataflow.erl"},{line,142}]}, >>> {dialyzer_succ_typings,collect_warnings,2, >>> [{file,"dialyzer_succ_typings.erl"},{line,182}]}]} >>> Last messages in the log cache: >>> Reading files and computing callgraph... done in 0.07 secs >>> Removing edges... done in 0.00 secs >>> >>> >>> 2. Running dialyzer on the module dt2 below raises the warning >>> following. Uncommenting the '%% ok' line has no effect. >>> >>> -module(dt2). >>> -export([get_map/0]). >>> >>> -spec get_map() -> map(). >>> get_map() -> >>> X = #{labels => [one, two], >>> number => 27, >>> %% [1,2,3] => wer, %% ok >>> kvok => #{ >>> a => qwe, >>> 2 => asd, >>> [1,2,3] => wer, %% bad >>> {4,5,6} => sdf, %% bad >>> "abc" => zxc >>> } >>> }, >>> X. >>> >>> $ dialyzer dt2.erl >>> Checking whether the PLT /home/ivan/.dialyzer_plt is up-to-date... >>> yes >>> Proceeding with analysis... >>> dt2.erl:5: Function get_map/0 has no local return >>> done in 0m0.41s >>> done (warnings were emitted) >>> >>> Best wishes >>> >>> Ivan >>> >>> >>> >>> >>> On 11/25/14 20:37, Dave Cottlehuber wrote: >>> >>>> Sorry about that last email ? >>>> >>>> EWORKSFORME. >>>> >>>> FreeBSD 10.1 amd64, erlang-17.3_2,3 from pkg. >>>> >>>> What FreeBSD & erlang are you using? >>>> >>>> dch /tmp ??? dialyzer --build_plt --apps erts kernel stdlib >>>> Creating PLT /home/dch/.dialyzer_plt ... >>>> Unknown functions: >>>> compile:file/2 >>>> compile:forms/2 >>>> compile:noenv_forms/2 >>>> compile:output_generated/1 >>>> crypto:block_decrypt/4 >>>> crypto:start/0 >>>> Unknown types: >>>> compile:option/0 >>>> done in 1m8.53s >>>> done (passed successfully) >>>> >>>> dch /tmp ???dialyzer ltu.erl >>>> Checking whether the PLT /home/dch/.dialyzer_plt is up-to-date... yes >>>> Proceeding with analysis... done in 0m0.41s >>>> done (passed successfully) >>>> >>>> dch /tmp ???erl >>>> Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] [async-threads:64] >>>> [kernel-poll:true] >>>> >>>> Eshell V6.2 (abort with ^G) >>>> 1> >>>> >>>> A+, Dave >>>> ? sent from my Couch >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> @llaisdy >>> llaisdy.wordpress.com >>> github.com/llaisdy >>> www.linkedin.com/in/ivanuemlianin >>> >>> festina lente >>> ============================================================ >>> >>> _______________________________________________ >>> 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 ali.sabil@REDACTED Fri Mar 13 11:35:08 2015 From: ali.sabil@REDACTED (Ali Sabil) Date: Fri, 13 Mar 2015 11:35:08 +0100 Subject: [erlang-questions] Why does Dialyzer crash on this map? In-Reply-To: References: <54749C90.6000602@llaisdy.com> <5474BA4C.4030706@llaisdy.com> <547716F8.7010208@llaisdy.com> <4B9AEB77-A709-4D97-8EF2-8FE1AF5A4071@llaisdy.com> Message-ID: Tried with the OTP master, and the issue is still there. On Fri, Mar 13, 2015 at 11:20 AM, Ali Sabil wrote: > Has this been solved for 17.4? I am getting the same crash on a quite > large code base using 17.4.1 > > Thanks, > Ali > > On Thu, Nov 27, 2014 at 10:05 PM, Ivan Uemlianin wrote: > >> Dear Bj?rn-Egil >> >> Thanks very much for your work and for reporting back. It looks like good >> news (for me and for 18 at least). >> >> Best wishes >> >> Ivan >> >> -- >> festina lente >> >> >> On 27 Nov 2014, at 20:52, Bj?rn-Egil Dahlberg < >> wallentin.dahlberg@REDACTED> wrote: >> >> Looks like the regression was introduced in >> 'hb/dialyzer/fix_recognition_of_records/OTP-11935' >> (805f9c89fc01220bc1bb0f27e1b68fd4eca688ba) included from OTP 17.1 >> >> This becomes a none-issue in the master branch (for 18) since variables >> are allowed as keys there but it needs to be solved for the 17 track. >> >> >> 2014-11-27 21:13 GMT+01:00 Bj?rn-Egil Dahlberg < >> wallentin.dahlberg@REDACTED>: >> >>> I managed to reproduce your errors on dt.erl and dt2.erl using >>> OTP-17.3.3 tag. >>> >>> Seems like I've missed something in dataflow .. looks like a clause >>> missing for the map type. >>> I'm not well versed in dialyzer. Hopefully I can do a fix for it for >>> 17.4. >>> >>> There are a bit more stuff going on here too. When dialyzer uses the >>> erlang compiler to compile to core >>> it does not coalesce things to literals but keeps them abstract instead >>> .. >>> Compound keys such as [1,2,3] and {4,5,6} will thus become non-literals >>> (variables) and such keys are not allowed in maps. >>> >>> I need to ponder that a bit before I try to solve it. >>> >>> // Bj?rn-Egil >>> >>> 2014-11-27 13:20 GMT+01:00 Ivan Uemlianin : >>> >>>> Dear Dave >>>> >>>> Thanks for your help. Here are some more details: >>>> >>>> >>>> *** OS: FreeBSD 10.0-RELEASE >>>> >>>> $ uname -a >>>> FreeBSD simba 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 >>>> 22:34:59 UTC 2014 root@REDACTED:/usr/obj/usr/src/sys/GENERIC >>>> amd64 >>>> >>>> Upgrading to 10.1 is on my todo list. >>>> >>>> >>>> *** Erlang version now 17.3_3,3 >>>> >>>> $ pkg info erlang >>>> erlang-17.3_1,3 >>>> ... >>>> $ sudo pkg upgrade >>>> ... >>>> >>>> $ pkg info erlang >>>> erlang-17.3_3,3 >>>> ... >>>> >>>> >>>> *** Errors persist >>>> >>>> Upgrading erlang has not changed behaviour. >>>> >>>> A couple more observations: >>>> >>>> 1. Running dialyzer on the module dt below gets the error as noted >>>> previously. However, if I uncomment the '%% ok' line, dialyzer will >>>> process the module with no problems. >>>> >>>> -module(dt). >>>> -export([get_map/0]). >>>> >>>> -spec get_map() -> map(). >>>> get_map() -> >>>> #{labels => [one, two], >>>> number => 27, >>>> %% [1,2,3] => wer, %% ok >>>> kvok => #{ >>>> a => qwe, >>>> 2 => asd, >>>> [1,2,3] => wer, %% bad >>>> {4,5,6} => sdf, %% bad >>>> "abc" => zxc >>>> } >>>> }. >>>> >>>> $ dialyzer dt.erl >>>> Checking whether the PLT /home/ivan/.dialyzer_plt is >>>> up-to-date... yes >>>> Proceeding with analysis... >>>> =ERROR REPORT==== 27-Nov-2014::12:17:02 === >>>> Error in process <0.45.0> with exit value: >>>> {{case_clause,map},[{dialyzer_dataflow,find_terminals,1,[{ >>>> file,"dialyzer_dataflow.erl"},{line,3451}]},{dialyzer_ >>>> dataflow,find_terminals_list,3,[{file,"dialyzer_dataflow. >>>> erl"},{line,3504}]},{dialyzer_dataflow,classify_returns... >>>> >>>> >>>> dialyzer: Analysis failed with error: >>>> {{case_clause,map}, >>>> [{dialyzer_dataflow,find_terminals,1, >>>> [{file,"dialyzer_dataflow.erl"},{line,3451}]}, >>>> {dialyzer_dataflow,find_terminals_list,3, >>>> [{file,"dialyzer_dataflow.erl"},{line,3504}]}, >>>> {dialyzer_dataflow,classify_returns,1, >>>> [{file,"dialyzer_dataflow.erl"},{line,3443}]}, >>>> {dialyzer_dataflow,'-state__get_warnings/2-fun-0-',7, >>>> [{file,"dialyzer_dataflow.erl"},{line,2908}]}, >>>> {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, >>>> {dialyzer_dataflow,state__get_warnings,2, >>>> [{file,"dialyzer_dataflow.erl"},{line,2934}]}, >>>> {dialyzer_dataflow,get_warnings,5, >>>> [{file,"dialyzer_dataflow.erl"},{line,142}]}, >>>> {dialyzer_succ_typings,collect_warnings,2, >>>> [{file,"dialyzer_succ_typings.erl"},{line,182}]}]} >>>> Last messages in the log cache: >>>> Reading files and computing callgraph... done in 0.07 secs >>>> Removing edges... done in 0.00 secs >>>> >>>> >>>> 2. Running dialyzer on the module dt2 below raises the warning >>>> following. Uncommenting the '%% ok' line has no effect. >>>> >>>> -module(dt2). >>>> -export([get_map/0]). >>>> >>>> -spec get_map() -> map(). >>>> get_map() -> >>>> X = #{labels => [one, two], >>>> number => 27, >>>> %% [1,2,3] => wer, %% ok >>>> kvok => #{ >>>> a => qwe, >>>> 2 => asd, >>>> [1,2,3] => wer, %% bad >>>> {4,5,6} => sdf, %% bad >>>> "abc" => zxc >>>> } >>>> }, >>>> X. >>>> >>>> $ dialyzer dt2.erl >>>> Checking whether the PLT /home/ivan/.dialyzer_plt is >>>> up-to-date... yes >>>> Proceeding with analysis... >>>> dt2.erl:5: Function get_map/0 has no local return >>>> done in 0m0.41s >>>> done (warnings were emitted) >>>> >>>> Best wishes >>>> >>>> Ivan >>>> >>>> >>>> >>>> >>>> On 11/25/14 20:37, Dave Cottlehuber wrote: >>>> >>>>> Sorry about that last email ? >>>>> >>>>> EWORKSFORME. >>>>> >>>>> FreeBSD 10.1 amd64, erlang-17.3_2,3 from pkg. >>>>> >>>>> What FreeBSD & erlang are you using? >>>>> >>>>> dch /tmp ??? dialyzer --build_plt --apps erts kernel stdlib >>>>> Creating PLT /home/dch/.dialyzer_plt ... >>>>> Unknown functions: >>>>> compile:file/2 >>>>> compile:forms/2 >>>>> compile:noenv_forms/2 >>>>> compile:output_generated/1 >>>>> crypto:block_decrypt/4 >>>>> crypto:start/0 >>>>> Unknown types: >>>>> compile:option/0 >>>>> done in 1m8.53s >>>>> done (passed successfully) >>>>> >>>>> dch /tmp ???dialyzer ltu.erl >>>>> Checking whether the PLT /home/dch/.dialyzer_plt is up-to-date... >>>>> yes >>>>> Proceeding with analysis... done in 0m0.41s >>>>> done (passed successfully) >>>>> >>>>> dch /tmp ???erl >>>>> Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] >>>>> [async-threads:64] [kernel-poll:true] >>>>> >>>>> Eshell V6.2 (abort with ^G) >>>>> 1> >>>>> >>>>> A+, Dave >>>>> ? sent from my Couch >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> @llaisdy >>>> llaisdy.wordpress.com >>>> github.com/llaisdy >>>> www.linkedin.com/in/ivanuemlianin >>>> >>>> festina lente >>>> ============================================================ >>>> >>>> _______________________________________________ >>>> 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 imantc@REDACTED Fri Mar 13 11:50:40 2015 From: imantc@REDACTED (Imants Cekusins) Date: Fri, 13 Mar 2015 11:50:40 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: <6E84EF03-3F7E-426D-A930-B4B956A8EB92@cs.otago.ac.nz> References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> <6E84EF03-3F7E-426D-A930-B4B956A8EB92@cs.otago.ac.nz> Message-ID: What can I say Richard? You are right. From daniel.goertzen@REDACTED Fri Mar 13 14:03:05 2015 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 13 Mar 2015 08:03:05 -0500 Subject: [erlang-questions] NFI's and running multiple VM's In-Reply-To: References: Message-ID: Your options are: 1. Use the NIF wrapper and launch an Erlang node for each session. You can use distributed Erlang to make this seem like a single system, but I have doubts about this scaling well. 2. Forget the NIF and write a port process in the language of your choice. This will scale better. 3. Can you skip libspotify entirely and consume the spotify Web API? You could use native Erlang http clients in that case. This would scale best. On Thu, Mar 12, 2015 at 5:45 PM, Leandro Ostera wrote: > Hello there guys, > > I've been shoving tons of Erlang content down my > information-ingestion-system for the past few days, and I'll continue to do > so in the next few weeks while I embark on this strange land. > > Anywho, I wanted to say hi and thank everyone who either has spoken at (or > is planning to) that appears on the Erlang Solutions vimeo videos ?which > has been my main source of getting into this besides Fred Hebert's book > (got the rocking paperback edition)? or put up an article online somewhere. > Kudos for the great material. > > And for a beginners question... > > I was trying to use a quite old erlang wrapper around libspotify > , which seems to be defining a bunch > of NIFs, to make an audio streaming server that would keep N web-based > clients playing the same audio at (give or take milliseconds) the same > time. The problem is that according to one of the source files > , > it'd only be able to have one open Spotify session per VM, which of course > didn't sound too exciting. Is this a limitation of building the wrapper as > a set of NIFs? What'd be a way of not having these sessions attached to the > VM but instead maybe to a particular process that would take care of > buffering/streaming the audio? If the session was to stick to the VM, > what'd be a practical way of making this support 100 sessions (or upwards)? > I hope these questions make sense. > > Frankly, I've been postponing this day for the past 2 years or so. > Hopefully it's the right time now :) > > Thanks and cheers! > Leandro > > -- > Leandro Ostera > > Github | LinkedIn > | Facebook > | @leostera > > _______________________________________________ > 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 Fri Mar 13 14:33:41 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 13 Mar 2015 14:33:41 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: On Thu, Mar 12, 2015 at 10:59 PM, Imants Cekusins wrote: > *Computing* (Of a process > > or variable > ) > notable > to be > changed > during > a set period,for example > while > a program is running Others have said it as well, but you should be wary of taking this definition as fact. The words static and immutable are not well-defined in computing in general, being used for various different things, depending on what initial mind set you have. Often, the words are used to convey that "something" is not subject to change, but precisely *what* that something *is* varies. In other words, we are overloading the words and thus they work badly for definitions now. In theoretic computer science, the words doesn't even occur in most cases. Rather, you let a logic system speak for itself, wave your hands a bit and have people figure out what kind of static and/or immutable is meant for a given logic system. This cleverly avoids having to define the details of the word, since it is in the logical system. When you *do* use the word, you painstakingly nail it to the wall to make sure you and everyone else knows what is meant. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Fri Mar 13 14:43:33 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 13 Mar 2015 14:43:33 +0100 Subject: [erlang-questions] NFI's and running multiple VM's In-Reply-To: References: Message-ID: On Thu, Mar 12, 2015 at 11:45 PM, Leandro Ostera wrote: > I was trying to use a quite old erlang wrapper around libspotify > , which seems to be defining a bunch > of NIFs, to make an audio streaming server that would keep N web-based > clients playing the same audio at (give or take milliseconds) the same > time. The problem is that according to one of the source files > , > it'd only be able to have one open Spotify session per VM, which of course > didn't sound too exciting. > The library may not be thread-safe. That is, it assumes a single thread for access and it stores session information in global variables inside the library itself. You may want to check if there is a newer version of the library without these limitations. NIFs do support proper multithreading and local context, but the library needs to support it as well. The term you are looking for w.r.t the context are 'resources': http://www.erlang.org/doc/man/erl_nif.html#enif_resource_example -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc@REDACTED Fri Mar 13 14:51:28 2015 From: imantc@REDACTED (Imants Cekusins) Date: Fri, 13 Mar 2015 14:51:28 +0100 Subject: [erlang-questions] Immutable isn't static Was: Re: Process scope variable In-Reply-To: References: <130270E0-6C99-4677-92D0-9DBE6BA756E7@cs.otago.ac.nz> <54C255F9-123E-4CBB-ACE8-43CF2103CE20@gmail.com> Message-ID: Jesper, Initially, I was looking for ways to use state within a process scope. (my apologies if words "state", "process" and "scope" are used incorrectly). I remember one person replying: use process dictionary. how this discussion ended up what it ended up as, is another topic. I am wondering, can I contribute to this discussion? Should I try? From community-manager@REDACTED Fri Mar 13 15:23:18 2015 From: community-manager@REDACTED (Bruce Yinhe) Date: Fri, 13 Mar 2015 15:23:18 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct Message-ID: Hi everyone, To encourage a welcoming, inclusive climate for communication within the erlang.org community, the Erlang/OTP team, together with members of the community, has released a new code of conduct, available at http://www.erlang.org/download/erlang_org_code_of_conduct.txt. This code of conduct lays out a guideline of how to communicate within the erlang.org community in a way we hope is easy to read, help mutual understanding and avoid flames. The erlang.org community is by definition all communication in or around erlang.org, including but not limited to the erlang.org mailing lists or Github discussions. This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter. http://www.erlang.org/download/erlang_org_code_of_conduct.txt -- Bruce Yinhe Erlang Community Manager Industrial Erlang User Group community-manager@REDACTED +46 72 311 43 89 -------------- next part -------------- An HTML attachment was scrubbed... URL: From t@REDACTED Fri Mar 13 15:44:38 2015 From: t@REDACTED (Tristan Sloughter) Date: Fri, 13 Mar 2015 09:44:38 -0500 Subject: [erlang-questions] Erlang Central source on Github Message-ID: <1426257878.2422701.239974249.2E8038F1@webmail.messagingengine.com> The top article under Erlang Times on http://erlangcentral.org/ right now is a 2011 article about ditching Erlang for Python. The article below it the link doesn't work -- would be nice to not use the frames either.. but that is a separate issue. It would be great if erlangcentral.org was on github so the community could submit pull requests. Besides the broken behavior I mentioned there is also the colors and fonts that make reading anything on erlangcentral.org near impossible. I'm posting this here because it should be a community effort, and I'm no better at web design but maybe someone here is :) -- Tristan Sloughter t@REDACTED From essen@REDACTED Fri Mar 13 15:47:09 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 13 Mar 2015 15:47:09 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <5502F86D.1090705@ninenines.eu> Hello, I see little need for a code of conduct that basically says "be nice". It's common sense after all. However I detect an issue in the document you linked, that probably also shouldn't be in a code of conduct. > It is pointless to send a message that only warns about posting style. > If you are trying to point someone to correct posting style > guidelines, please do so while at least honestly attempting to answer > their questions or comments. It is generally unhelpful to give only a > warning related to posting style, as newcomers may feel unwelcome, > only to leave. And that is exactly what we do not want. That's what you'll inevitably get now that you made a number of official "rules" for posting style. And you'll also get the associated frame wars about top and bottom posting. > 4. Top posting is discouraged.*** Hence, try to put the quoted content > first, so that people can know what you are replying to before > they read the reply. In a world where the most used clients use top posting by default, this rule makes little sense. > 5. Try to break your lines at around 74 characters. This makes > printing and reading e-mail on many clients easier and more > consistent with how you intended the message to be. Same here, the most used clients don't exactly show you the column number, this can't apply to HTML emails and many don't give you an option to control the formatting, whether text is the main type or the fallback to HTML. I know a few people are attached to their console clients and 80 character windows but at some point you have to be pragmatic and keep in mind what the majority of people use. Please don't start a flame war over this post. :-) Cheers, -- Lo?c Hoguin http://ninenines.eu From mononcqc@REDACTED Fri Mar 13 16:25:43 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 13 Mar 2015 11:25:43 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5502F86D.1090705@ninenines.eu> References: <5502F86D.1090705@ninenines.eu> Message-ID: <20150313152541.GP63925@ferdair.local> On 03/13, Lo?c Hoguin wrote: > I see little need for a code of conduct that basically says "be nice". It's > common sense after all. > Then the code of conduct shall not be a problem for you. What the code does, however, is put a context around when and how someone can be reprimanded on the list, and for what reasons. It also gives a path of escalation in case of disagreement. Without one, this is basically left implicit to whoever is swinging the banhammer, and who you know or can talk to. It sets expectations and context over what is expected from members *and* from moderators. > > It is pointless to send a message that only warns about posting style. > > If you are trying to point someone to correct posting style > > guidelines, please do so while at least honestly attempting to answer > > their questions or comments. It is generally unhelpful to give only a > > warning related to posting style, as newcomers may feel unwelcome, > > only to leave. And that is exactly what we do not want. > > That's what you'll inevitably get now that you made a number of official > "rules" for posting style. And you'll also get the associated frame wars > about top and bottom posting. Then it goes against the code of conduct, please don't do that. Moderation can do its job, as subtle as it may be to the onlooker, or you can brin your problems to the moderators. Their contact info is listed in the code of conduct. -- Regarding top or bottom posting, I don't have strong feelings either way, though I do get annoyed by gmail users never filtering down the quoted part of posts yielding exponentially larger threads when you use a client that doesn't fold quotes. Regards, Fred. From bchesneau@REDACTED Fri Mar 13 16:49:25 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Fri, 13 Mar 2015 15:49:25 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <20150313152541.GP63925@ferdair.local> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> Message-ID: On Fri, Mar 13, 2015 at 4:25 PM Fred Hebert wrote: > On 03/13, Lo?c Hoguin wrote: > > I see little need for a code of conduct that basically says "be nice". > It's > > common sense after all. > > > > Then the code of conduct shall not be a problem for you. > > What the code does, however, is put a context around when and how > someone can be reprimanded on the list, and for what reasons. It also > gives a path of escalation in case of disagreement. Without one, this is > basically left implicit to whoever is swinging the banhammer, and who > you know or can talk to. > > It sets expectations and context over what is expected from members > *and* from moderators. > > > > It is pointless to send a message that only warns about posting style. > > > If you are trying to point someone to correct posting style > > > guidelines, please do so while at least honestly attempting to answer > > > their questions or comments. It is generally unhelpful to give only a > > > warning related to posting style, as newcomers may feel unwelcome, > > > only to leave. And that is exactly what we do not want. > > > > That's what you'll inevitably get now that you made a number of official > > "rules" for posting style. And you'll also get the associated frame wars > > about top and bottom posting. > > Then it goes against the code of conduct, please don't do that. > Moderation can do its job, as subtle as it may be to the onlooker, or > you can brin your problems to the moderators. Their contact info is > listed in the code of conduct. > > -- > > Regarding top or bottom posting, I don't have strong feelings either > way, though I do get annoyed by gmail users never filtering down the > quoted part of posts yielding exponentially larger threads when you use > a client that doesn't fold quotes. > > Regards, > Fred. > > Why do we need a code of conduct now when we lived without it for so long? Also since we are speaking of a community who/when was discussed that document? Where can I find a list of the moderators? Also i agree discouraging people to not do top posting when most modern client use it as a default sounds weird and not very welcoming for the new generation... - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Mar 13 16:54:13 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 13 Mar 2015 16:54:13 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <20150313152541.GP63925@ferdair.local> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> Message-ID: <55030825.7080404@ninenines.eu> On 03/13/2015 04:25 PM, Fred Hebert wrote: > On 03/13, Lo?c Hoguin wrote: >> I see little need for a code of conduct that basically says "be nice". It's >> common sense after all. >> > > Then the code of conduct shall not be a problem for you. > > What the code does, however, is put a context around when and how > someone can be reprimanded on the list, and for what reasons. It also > gives a path of escalation in case of disagreement. Without one, this is > basically left implicit to whoever is swinging the banhammer, and who > you know or can talk to. > > It sets expectations and context over what is expected from members > *and* from moderators. I am not so concerned about my behavior. Read it or not, most people will post fine. I am more concerned about the side effects of rules. When you write down rules, you always end up with some unrelated people trying to enforce these rules, despite it not being their job. This can create unnecessary conflicts. A number of these people will also try to enforce the word of the rules rather than their spirit. There also doesn't seem to be in the CoC an explanation of the process to either defend yourself (as you point out, not everyone is native English speaker, so misunderstanding happen and they do quite regularly), nor is there an explanation for how to redeem yourself. This is a problem to me because every few months I manage to offend someone without meaning it. A few weeks ago I got attacked when all I tried to do was make a compliment, to give you an example. And as Benoit points out, it's a concern that we don't know who the moderators are and how they are selected. I have seen way too often moderators ban people on a whim due to personal issues rather than rules being broken. -- Lo?c Hoguin http://ninenines.eu From mononcqc@REDACTED Fri Mar 13 16:56:09 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 13 Mar 2015 11:56:09 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> Message-ID: <20150313155608.GQ63925@ferdair.local> On 03/13, Benoit Chesneau wrote: > Why do we need a code of conduct now when we lived without it for so long? That we haven't needed one doesn't mean we won't ever, or that others than you and I haven't felt the need for one before. I haven't been the one to bring forth the idea of having a code of conduct, but I'm generally fine with one. > Also since we are speaking of a community who/when was discussed that > document? Where can I find a list of the moderators? > It's in the code of conduct, listed as: Moderators: *-owner@REDACTED e.g. erlang-questions-owner@REDACTED It doesn't say *who* is a moderator as a human being, and maybe that's a weakness, but it gives you their email addresses to contact them and know when they are contacting you. Regards, Fred. From mononcqc@REDACTED Fri Mar 13 17:02:48 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 13 Mar 2015 12:02:48 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <55030825.7080404@ninenines.eu> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <55030825.7080404@ninenines.eu> Message-ID: <20150313160247.GR63925@ferdair.local> On 03/13, Lo?c Hoguin wrote: > When you write down rules, you always end up with some unrelated people > trying to enforce these rules, despite it not being their job. This can > create unnecessary conflicts. A number of these people will also try to > enforce the word of the rules rather than their spirit. > The rules also ask them not to enforce the rules on their own, so they might be bad enforcers, but frankly, that's a problem for then and there. In any case, I don't understand how you can be worried about yet-non-existent rule-enforcers, but you are not worried by yet-non-existent rule-breakers. Something is not logical there. > There also doesn't seem to be in the CoC an explanation of the process to > either defend yourself (as you point out, not everyone is native English > speaker, so misunderstanding happen and they do quite regularly), nor is > there an explanation for how to redeem yourself. "To lift a ban or otherwise contend a regulative measure, contact mailman@REDACTED" Is all that's mentioned. I'm guessing they'll go at it case-by-case for this? > > This is a problem to me because every few months I manage to offend > someone without meaning it. A few weeks ago I got attacked when all I > tried to do was make a compliment, to give you an example. > I'm guessing people here are humans, and if they can understand without a code of conduct, surely they can understand with one involved as well. > And as Benoit points out, it's a concern that we don't know who the > moderators are and how they are selected. I have seen way too often > moderators ban people on a whim due to personal issues rather than > rules being broken. > See my response to Benoit. From n.oxyde@REDACTED Fri Mar 13 17:26:47 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Mar 2015 17:26:47 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <2572CC66-5C87-45BD-8718-7DCB6E47DC61@gmail.com> Le 13 mars 2015 ? 15:23, Bruce Yinhe a ?crit : > Hi everyone, > > To encourage a welcoming, inclusive climate for communication within the erlang.org community, the Erlang/OTP team, together with members of the community, has released a new code of conduct, available at http://www.erlang.org/download/erlang_org_code_of_conduct.txt. This code of conduct lays out a guideline of how to communicate within the erlang.org community in a way we hope is easy to read, help mutual understanding and avoid flames. The erlang.org community is by definition all communication in or around erlang.org, including but not limited to the erlang.org mailing lists or Github discussions. > > This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter. > > http://www.erlang.org/download/erlang_org_code_of_conduct.txt I was wondering why I woke up with urticaria. I should have looked at erlang-questions to know why. From essen@REDACTED Fri Mar 13 17:27:49 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 13 Mar 2015 17:27:49 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <20150313160247.GR63925@ferdair.local> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <55030825.7080404@ninenines.eu> <20150313160247.GR63925@ferdair.local> Message-ID: <55031005.6080705@ninenines.eu> On 03/13/2015 05:02 PM, Fred Hebert wrote: > On 03/13, Lo?c Hoguin wrote: >> When you write down rules, you always end up with some unrelated people >> trying to enforce these rules, despite it not being their job. This can >> create unnecessary conflicts. A number of these people will also try to >> enforce the word of the rules rather than their spirit. >> > > The rules also ask them not to enforce the rules on their own, so they > might be bad enforcers, but frankly, that's a problem for then and > there. So if you try to enforce the rules they can get a warning, be moderated and then banned? Also would say "that's a problem for then and there" is a good quote about when to introduce a CoC, but that's a little too late for that now. > In any case, I don't understand how you can be worried about > yet-non-existent rule-enforcers, but you are not worried by > yet-non-existent rule-breakers. Something is not logical there. We already have rule enforcers though. Top/bottom posting came up many times already, to give an example. What happens by adding these explicit rules is simply to comfort enforcers that what they already did is right. >> There also doesn't seem to be in the CoC an explanation of the process to >> either defend yourself (as you point out, not everyone is native English >> speaker, so misunderstanding happen and they do quite regularly), nor is >> there an explanation for how to redeem yourself. > > "To lift a ban or otherwise contend a regulative measure, contact > mailman@REDACTED" > > Is all that's mentioned. I'm guessing they'll go at it case-by-case for > this? ... >> And as Benoit points out, it's a concern that we don't know who the >> moderators are and how they are selected. I have seen way too often >> moderators ban people on a whim due to personal issues rather than >> rules being broken. >> > > See my response to Benoit. It's not really reassuring. Basically it's all up to The Man. -- Lo?c Hoguin http://ninenines.eu From peterhickman386@REDACTED Fri Mar 13 17:23:09 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Fri, 13 Mar 2015 16:23:09 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <20150313160247.GR63925@ferdair.local> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <55030825.7080404@ninenines.eu> <20150313160247.GR63925@ferdair.local> Message-ID: Well this makes me very uncomfortable :( Despite being a lurker the introduction of arbitrary and subjective rules such as 74 character limit and no top posting, neither of which have ever caused me problems, comes off as someone having too much time on their hands. 3. Be mindful of how much text you are quoting. Too much or too little doesn't help. Could you please provide guidance on what constitutes "too much" or "too little" quoting. I will be expecting citations from peer reviewed journals - or is this just the whim of an anonymous mod? I am a member of a few language based communities, some which have been much less professional than this list, and they thrived without having Moses coming down with the tablets to inform us how we should format our emails. Why you think that this even needs to be introduced? Did I miss some great cataclysm? The lack of a need for a CoC makes me think badly of those that are motivated to introduce one. (But I will accept that it all comes down to people with nothing better to do) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri Mar 13 18:03:00 2015 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 13 Mar 2015 17:03:00 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> Message-ID: <17C78821-86BF-43BB-8A41-F5D0C6481BDE@llaisdy.com> Didn't you notice? Codes of conduct were like majorly flavour of the month in February. -- festina lente > On 13 Mar 2015, at 15:49, Benoit Chesneau wrote: > > >> On Fri, Mar 13, 2015 at 4:25 PM Fred Hebert wrote: >> On 03/13, Lo?c Hoguin wrote: >> > I see little need for a code of conduct that basically says "be nice". It's >> > common sense after all. >> > >> >> Then the code of conduct shall not be a problem for you. >> >> What the code does, however, is put a context around when and how >> someone can be reprimanded on the list, and for what reasons. It also >> gives a path of escalation in case of disagreement. Without one, this is >> basically left implicit to whoever is swinging the banhammer, and who >> you know or can talk to. >> >> It sets expectations and context over what is expected from members >> *and* from moderators. >> >> > > It is pointless to send a message that only warns about posting style. >> > > If you are trying to point someone to correct posting style >> > > guidelines, please do so while at least honestly attempting to answer >> > > their questions or comments. It is generally unhelpful to give only a >> > > warning related to posting style, as newcomers may feel unwelcome, >> > > only to leave. And that is exactly what we do not want. >> > >> > That's what you'll inevitably get now that you made a number of official >> > "rules" for posting style. And you'll also get the associated frame wars >> > about top and bottom posting. >> >> Then it goes against the code of conduct, please don't do that. >> Moderation can do its job, as subtle as it may be to the onlooker, or >> you can brin your problems to the moderators. Their contact info is >> listed in the code of conduct. >> >> -- >> >> Regarding top or bottom posting, I don't have strong feelings either >> way, though I do get annoyed by gmail users never filtering down the >> quoted part of posts yielding exponentially larger threads when you use >> a client that doesn't fold quotes. >> >> Regards, >> Fred. > > > Why do we need a code of conduct now when we lived without it for so long? Also since we are speaking of a community who/when was discussed that document? Where can I find a list of the moderators? > > Also i agree discouraging people to not do top posting when most modern client use it as a default sounds weird and not very welcoming for the new generation... > > - benoit > > _______________________________________________ > 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 13 18:04:46 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 13 Mar 2015 13:04:46 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <55030825.7080404@ninenines.eu> <20150313160247.GR63925@ferdair.local> Message-ID: <20150313170445.GS63925@ferdair.local> On 03/13, Peter Hickman wrote: > Well this makes me very uncomfortable :( > > Despite being a lurker the introduction of arbitrary and subjective rules > such as 74 character limit and no top posting, neither of which have ever > caused me problems, comes off as someone having too much time on their > hands. I'm not behind the initiative of having a code of conduct, but I was brought in to help with some wording and some clauses. I don't know what it is like to moderate these mailing lists, but for the places (forums, IRC channels, meetups) I have helped moderate, they can be nice for a few reasons, the leats of which is crystalizing the criteria by which you moderate already. The idea of these rules is to take what is currently taking place and make it obvious, so that when someone does something bad, the moderator can point their way and go "this is the rule we enforce, please respect it" rather than just improvising the rules they enforce. The idea is not to introduce new rules, it's to make them explicit. If you didn't feel threatened before and never received a warning, there's no reason you should be now. > > 3. Be mindful of how much text you are quoting. Too much or too > little doesn't help. > > Could you please provide guidance on what constitutes "too much" or "too > little" quoting. I will be expecting citations from peer reviewed journals > - or is this just the whim of an anonymous mod? > I believe it is at the whim of an anonymous mod, as it was before a code of conduct. Nothing changed there. I've been told people received warnings before for extremely long top-posting with large quotes. It was, I believe (because I have never seen it or been warned) done in private, and nobody felt the pressure of 'the man' stamping their boots on their neck. > I am a member of a few language based communities, some which have been > much less professional than this list, and they thrived without having > Moses coming down with the tablets to inform us how we should format our > emails. Why you think that this even needs to be introduced? Did I miss > some great cataclysm? > Do you believe no rules were enforced before today? As far as I can tell they were enforced. Now we just have a better idea what they are. Ericsson had moderators in here and still do. It's not Moses coming down with the tablets to inform you of new rules, It's Moses coming down to tell you what rules were already there but you judt didn't know about. That's the distinction this Code of Conduct makes. It's not new law. It's current law, made explicit. If you haven't felt a problem with the list before, I don'T think there's any reason to feel them now. From vincent.dephily@REDACTED Fri Mar 13 18:53:27 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 13 Mar 2015 18:53:27 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <20150313160247.GR63925@ferdair.local> Message-ID: <2204884.bImhu0VMbI@moltowork> On Friday 13 March 2015 16:23:09 Peter Hickman wrote: > Despite being a lurker the introduction of arbitrary and subjective rules > such as 74 character limit and no top posting, neither of which have ever > caused me problems, comes off as someone having too much time on their > hands. I could care less about 74 chars, and find html-only emails annoying but not deal-breakers. But top-posting and improper quoting really make threads harder to follow. Top-posting is ok in some contexts, but on a mailing list read by lots of busy people, I find it disrespectful of reader's time. > 3. Be mindful of how much text you are quoting. Too much or too > little doesn't help. > > Could you please provide guidance on what constitutes "too much" or "too > little" quoting. I will be expecting citations from peer reviewed journals > - or is this just the whim of an anonymous mod? Just like "hatefull, hurtfull... remarks" this is subjective. Why worry about one subjective criteria but not the other ? For these subjective metrics, I expect moderation to take place only if somebody goes repeatedly way overboard. I'd also expect that moderation to be proportionate to the "offense" : surely bad formating (as opposed to hateful remarks) should lead at most to comments as part of a response, never a ban. Note that the document distinguishes "Content policy" from "Style policy". > I am a member of a few language based communities, some which have been > much less professional than this list, and they thrived without having > Moses coming down with the tablets to inform us how we should format our > emails. Why you think that this even needs to be introduced? Did I miss > some great cataclysm? > > The lack of a need for a CoC makes me think badly of those that are > motivated to introduce one. CoC are documents which should be writen ahead of time. When a problem happens, if a CoC was not established to steer things back into normalcy quickly, you're likely to lose community members. "Let it crash" is good for Erlang, but not for its community. Some people who have been hurt before will simply not participate in a community or an event without a CoC. FWIW, I think this CoC is fairly light and just codifies the current practice. The only bit I'd remove is the 74 char limit (even though I respect it by way of mailer config). -- Vincent de Phily From k.petrauskas@REDACTED Fri Mar 13 19:53:34 2015 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Fri, 13 Mar 2015 20:53:34 +0200 Subject: [erlang-questions] os:timestamp/0 and erlang:now/0 Message-ID: Hello, I have noticed strange behaviour on one of our erlang nodes. erlang:now() returns smaller values, than os:timestamp(). I thought, it could be opposite in some hi-load situations, but this surprised me. The following test reproduces the situation on that particular node (N >= T is false), while it returns true on newly created VMs. f(T), f(N), T = os:timestamp(), N = erlang:now(), {N >= T, T, N}. {false,{1426,271957,819043},{1426,271957,809685}} The node runs `Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false]` on Linux running on a virtual machine. The node has no noticeable load, not more than several transactions per minute. Is this normal behaviour, or I found a bug? Karolis From mononcqc@REDACTED Fri Mar 13 20:02:51 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 13 Mar 2015 15:02:51 -0400 Subject: [erlang-questions] os:timestamp/0 and erlang:now/0 In-Reply-To: References: Message-ID: <20150313190249.GT63925@ferdair.local> Do you run any arguments regarding time correction (+c) ? The doc mentions: +c Disable compensation for sudden changes of system time. Normally, erlang:now/0 will not immediately reflect sudden changes in the system time, in order to keep timers (including receive-after) working. Instead, the time maintained by erlang:now/0 is slowly adjusted towards the new system time. (Slowly means in one percent adjustments; if the time is off by one minute, the time will be adjusted in 100 minutes.) When the +c option is given, this slow adjustment will not take place. Instead erlang:now/0 will always reflect the current system time. Note that timers are based on erlang:now/0. If the system time jumps, timers then time out at the wrong time. NOTE: You can check whether the adjustment is enabled or disabled by calling erlang:system_info(tolerant_timeofday). It is possible that time has drifted forwards a bit and for a period of time, now() returns a time lagging behind os:timestamp() because it is still compensating and catching up to the absolute time change. From k.petrauskas@REDACTED Fri Mar 13 20:23:33 2015 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Fri, 13 Mar 2015 21:23:33 +0200 Subject: [erlang-questions] os:timestamp/0 and erlang:now/0 In-Reply-To: <20150313190249.GT63925@ferdair.local> References: <20150313190249.GT63925@ferdair.local> Message-ID: I have specified no special arguments for time correction, at least explicitly. `erlang:system_info(tolerant_timeofday).` returns `enabled`. It is very likely, that the system time was adjusted. Although the difference between now() and os:timestamp() is not decreasing and varies between 9.340 and 9.387 ms (I'm observing this for a half of the day already). Karolis On Fri, Mar 13, 2015 at 9:02 PM, Fred Hebert wrote: > Do you run any arguments regarding time correction (+c) ? The doc > mentions: > > +c > > Disable compensation for sudden changes of system time. > > Normally, erlang:now/0 will not immediately reflect sudden > changes in the system time, in order to keep timers (including > receive-after) working. Instead, the time maintained by > erlang:now/0 is slowly adjusted towards the new system time. > (Slowly means in one percent adjustments; if the time is off by > one minute, the time will be adjusted in 100 minutes.) > > When the +c option is given, this slow adjustment will not > take place. Instead erlang:now/0 will always reflect the > current system time. Note that timers are based on > erlang:now/0. If the system time jumps, timers then time out > at the wrong time. > > NOTE: You can check whether the adjustment is enabled or > disabled by calling > erlang:system_info(tolerant_timeofday). > > It is possible that time has drifted forwards a bit and for a period of > time, now() returns a time lagging behind os:timestamp() because it is > still compensating and catching up to the absolute time change. From darach@REDACTED Fri Mar 13 20:41:50 2015 From: darach@REDACTED (Darach Ennis) Date: Fri, 13 Mar 2015 19:41:50 +0000 Subject: [erlang-questions] os:timestamp/0 and erlang:now/0 In-Reply-To: References: <20150313190249.GT63925@ferdair.local> Message-ID: Hi Karolis, Out of curiosity, why are you comparing os:timestamp() to erlang:now()? There is a possibility that frequent calls to erlang:now() runs ahead of the clock as it must deliver unique values (guaranteed) whereas os:timestamp() does not have this property. This alone may produce the behaviour you are seeing independent of other variables (eg: +c). I wouldn't have considered either to be reasonably or easily comparable against each other. However, comparing one fun to precedent values returned by the same fun should exhibit the relative behaviour you desire and correlate as you expect. But comparing os:timestamp to erlang:now doesn't seem supportable as they behave differently by design. Hence, curious as to your use case and why you are comparing these two distinct functions. Cheers, Darach. On Fri, Mar 13, 2015 at 7:23 PM, Karolis Petrauskas wrote: > I have specified no special arguments for time correction, at least > explicitly. `erlang:system_info(tolerant_timeofday).` returns > `enabled`. > > It is very likely, that the system time was adjusted. Although the > difference between now() and os:timestamp() is not decreasing and > varies between 9.340 and 9.387 ms (I'm observing this for a half of > the day already). > > Karolis > > On Fri, Mar 13, 2015 at 9:02 PM, Fred Hebert wrote: > > Do you run any arguments regarding time correction (+c) ? The doc > > mentions: > > > > +c > > > > Disable compensation for sudden changes of system time. > > > > Normally, erlang:now/0 will not immediately reflect sudden > > changes in the system time, in order to keep timers (including > > receive-after) working. Instead, the time maintained by > > erlang:now/0 is slowly adjusted towards the new system time. > > (Slowly means in one percent adjustments; if the time is off by > > one minute, the time will be adjusted in 100 minutes.) > > > > When the +c option is given, this slow adjustment will not > > take place. Instead erlang:now/0 will always reflect the > > current system time. Note that timers are based on > > erlang:now/0. If the system time jumps, timers then time out > > at the wrong time. > > > > NOTE: You can check whether the adjustment is enabled or > > disabled by calling > > erlang:system_info(tolerant_timeofday). > > > > It is possible that time has drifted forwards a bit and for a period of > > time, now() returns a time lagging behind os:timestamp() because it is > > still compensating and catching up to the absolute time change. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Fri Mar 13 21:43:10 2015 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Fri, 13 Mar 2015 22:43:10 +0200 Subject: [erlang-questions] os:timestamp/0 and erlang:now/0 In-Reply-To: References: <20150313190249.GT63925@ferdair.local> Message-ID: On Fri, Mar 13, 2015 at 9:41 PM, Darach Ennis wrote: > Hi Karolis, > > Out of curiosity, why are you comparing os:timestamp() to erlang:now()? I found a bug in my software, related to the system time. Then I noticed mismatch of time values in the log messages and log timestamps. I expected that erlang:now() >= os:timestamp() at any point in time, but that rendered to be false. That's why I decided to ask this question here. My bugfix ended up by not using system time in that place at all. > There is a possibility that frequent calls to erlang:now() runs ahead of the > clock as it must deliver unique values (guaranteed) whereas os:timestamp() > does not have this property. This alone may produce the behaviour you are > seeing independent of other variables (eg: +c). Yes, but I observe the opposite. > I wouldn't have considered either to be reasonably or easily comparable > against > each other. However, comparing one fun to precedent values returned by the > same fun should exhibit the relative behaviour you desire and correlate as > you > expect. But comparing os:timestamp to erlang:now doesn't seem supportable > as they behave differently by design. Yes, that was the cause for the bug. I was taking system time (erlang:now()), truncating milliseconds from it and therefore got rounding errors increased to unexpected level. The following investigation is just because of curiosity. > Hence, curious as to your use case and why you are comparing these two > distinct functions. > > Cheers, > > Darach. Karolis From darach@REDACTED Fri Mar 13 22:19:59 2015 From: darach@REDACTED (Darach Ennis) Date: Fri, 13 Mar 2015 21:19:59 +0000 Subject: [erlang-questions] os:timestamp/0 and erlang:now/0 In-Reply-To: References: <20150313190249.GT63925@ferdair.local> Message-ID: Hi Karolis, I'm glad you've found the right path. :) The benchmark you came up with might be interesting to the temporally obsessed on this list (such as myself) if you think it is worth posting. You may have stumbled onto something unexpected or surprising that would be worth analysing further. However, micro-benchmarking can often result in learning as much or more about micro-benchmarking than the target under the microscope. Cheers, Darach. On Fri, Mar 13, 2015 at 8:43 PM, Karolis Petrauskas wrote: > On Fri, Mar 13, 2015 at 9:41 PM, Darach Ennis wrote: > > Hi Karolis, > > > > Out of curiosity, why are you comparing os:timestamp() to erlang:now()? > > I found a bug in my software, related to the system time. Then I > noticed mismatch of time values in the log messages and log > timestamps. I expected that erlang:now() >= os:timestamp() at any > point in time, but that rendered to be false. That's why I decided to > ask this question here. My bugfix ended up by not using system time in > that place at all. > > > There is a possibility that frequent calls to erlang:now() runs ahead of > the > > clock as it must deliver unique values (guaranteed) whereas > os:timestamp() > > does not have this property. This alone may produce the behaviour you are > > seeing independent of other variables (eg: +c). > > Yes, but I observe the opposite. > > > I wouldn't have considered either to be reasonably or easily comparable > > against > > each other. However, comparing one fun to precedent values returned by > the > > same fun should exhibit the relative behaviour you desire and correlate > as > > you > > expect. But comparing os:timestamp to erlang:now doesn't seem supportable > > as they behave differently by design. > > Yes, that was the cause for the bug. I was taking system time > (erlang:now()), truncating milliseconds from it and therefore got > rounding errors increased to unexpected level. The following > investigation is just because of curiosity. > > > Hence, curious as to your use case and why you are comparing these two > > distinct functions. > > > > Cheers, > > > > Darach. > > Karolis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhickman386@REDACTED Fri Mar 13 23:27:34 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Fri, 13 Mar 2015 22:27:34 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <2204884.bImhu0VMbI@moltowork> References: <20150313160247.GR63925@ferdair.local> <2204884.bImhu0VMbI@moltowork> Message-ID: Other than the 74 character limit (and just quite where that figure got pulled from is anyones guess) all the rules are subjective. This is why I ask what "too little" or "too much" quoting is, you could be banned for this, that is why they are there in the CoC in the first place. We can measure the length of a line and say "yes this person has broken the line length rule". Regardless of where we stand on line length we can at least objectively measure it. But should someone get pulled up for "too much" quoting then they are at the mercy of how the moderator is feeling that day. Your "too much" might be my "just right". Who is to say? The problem is that there is now someone who can say and can act on it too. ? How about you make a post that includes a line that is 74 characters long. I then quote that line, the '> ' that now prefixes the line pushes the line over the sacred 74 character limit. I have violated the CoC. God forbid that someone quotes me quoting you? The CoC also omits to mention how these bans are handled. Will the offence and associated evidence be presented to the community so that we know why Vincent de Phily is no longer active on the list or will the secret police simply ban him and pretend that he never existed? The potential for abuse is great. In the back of my mind I am seeing a corporation that is concerned that it's "social assets" are perhaps not behaving as they should and needs to be brought into line. I feel the need to put quotes around the word community. As I have said previously other much larger language communities have thrived without such rules and I fail to see why the Erlang community should be so fragile (or paranoid). -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Sat Mar 14 00:08:18 2015 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Sat, 14 Mar 2015 00:08:18 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: I have no problem with the content policy. Those were informal guidelines made explicit. I think it's good that we've made the intent of what information we want to share here explicit. That style policy though .. it reads like someone wants to desperately save their ancient mail client from the looming doom of progress. Well, 1 and 5 does at least. I'm looking suspiciously at you Raimo .. On the other hand, I do feel that some behavior should be encouraged while other behavior should not be. People should be mindful of the fact we actually try to sift through all the information given to us through the mailing-list. The easier it is to parse a mail discussion the better, for all of us. Long novells is not very helpful for me at least .. unless summarized it will fall under tl;dr;nt (no time). // Bj?rn-Egil 2015-03-13 15:23 GMT+01:00 Bruce Yinhe : > Hi everyone, > > To encourage a welcoming, inclusive climate for communication within the > erlang.org community, the Erlang/OTP team, together with members of the > community, has released a new code of conduct, available at > http://www.erlang.org/download/erlang_org_code_of_conduct.txt. This code > of conduct lays out a guideline of how to communicate within the > erlang.org community in a way we hope is easy to read, help mutual > understanding and avoid flames. The erlang.org community is by definition > all communication in or around erlang.org, including but not limited to > the erlang.org mailing lists or Github discussions. > > This code is not exhaustive or complete. It serves to distill our common > understanding of a collaborative, shared environment and goals. We expect > it to be followed in spirit as much as in the letter. > > http://www.erlang.org/download/erlang_org_code_of_conduct.txt > > > -- > Bruce Yinhe > Erlang Community Manager > Industrial Erlang User Group > community-manager@REDACTED > +46 72 311 43 89 > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Sat Mar 14 00:24:33 2015 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sat, 14 Mar 2015 00:24:33 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: > > I think if you ban/warn quality contributions because of style you will lo ose those contributions. Quality meaning someone got something positive ou t of it. Not sure if that is worth it? (quoted two empty lines as I am sure one would be to little and three would b e to much) -- Mark Nijhof K64 m: 0047 46748688 t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sat Mar 14 00:51:57 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 14 Mar 2015 00:51:57 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: On Fri, Mar 13, 2015 at 3:23 PM, Bruce Yinhe wrote: > This code of conduct lays out a guideline of how to communicate within the > erlang.org community in a way we hope is easy to read, help mutual > understanding and avoid flames. > If I were to critique something here, it would be that the current CoC mixes text on social interaction[-1] (that is, how to behave with respect to other people) from mailing list etiquette (how to quote, how to make older mail readers happy[0]). By mixing these two, it is somewhat harder to read the CoC and I am pretty sure there are different sanctions if I decide to call someone a quebecois trying to speak proper french (in earnest), or if I write a single line at 75 characters (where the last one is ASCII decimal 32 naturally). Say we add a bug tracker to erlang.org in the future. It would be logical to extend the CoC to the bug tracker as well. I've seen my share of inappropriate behaviour in bug trackers, sadly. This is why I'd like to make a point that proactively, it would be nice to think about how different sections of the documents fit into categories, so the generic parts are really generic, and the etiquette-parts specific to a communication medium have their own sections. On the question of the necessity of a CoC itself, I'll politely pass. While I don't personally see the benefit of CoCs in most projects, I do respect that this is not the view of many others. I much prefer the FreeBSD developers handbook approach than anything else. I do note that a large project, like Erlang, which isn't driven by a single monarch overseeing its construction, is better served by a well-defined code. If escalation is necessary in a certain situation, it is nice to know in advance which Tribunal you will be judged by, however. If governed by a despot, you already know who it is, but for a grouped project, the definitions are better laid down. The CoC might get flak in the future for not being inclusive enough, too terse, or damaging to some greater cause. A great recent example was the Linux Kernel's Code of Conflict. Who handles suggestions for changes, what is the process of changes, and do we track changes somewhere, so one can see the additions and removals of wording? Like in other societies, codes are not static/immutable/constant once laid down, but dynamic/mutable/volatile and thus subject to change as we learn. I've been calling for the CoC equivalent of the software license, with versioning, so it would be easier to discriminate them from each other. But we are not far enough for this to happen yet. Other than that, I think it looks nice. The content-guidelines on social interaction is always nice to lay down formally as they were once informal. I'm +1'ing Mr. Dahlberg here. The guidelines on etiquette reads like 1998 to me, which is not necessarily a bad thing, but it may feel unnecessary technical to some. What mail clients behave nicely out-of-the-box by default with the current etiquette guidelines? [-1] Bj?rn-Egil calls this 'content'. [0] If you use Pine, I'll shoot you, sorry :) Mutt is okay though. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.rosenblum@REDACTED Sat Mar 14 01:52:59 2015 From: jim.rosenblum@REDACTED (Jim) Date: Fri, 13 Mar 2015 20:52:59 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Condu In-Reply-To: References: Message-ID: <0A3D542F-C398-46ED-A04E-55F022EDE85A@gmail.com> Folks, I love the Erlang eco-system, and by "Eco-system" I include the beam, the language - syntax included - and *this* community. I read the digest every day and have tried to post only sparingly. I have benefitted from the groups' generosity more than once and would like to pay that generosity back. So, I am confused by the CoC because I don't understand what existing problem it is designed to solve. The very few examples of friction I have seen seemed to end quickly and, in general, provide as much entertainment as frustration. Having said this, I could get behind and even advocate for a CoC if I better understood what problem we are trying to solve. If the problem is worse than the medicine, I always take the medicine. From jim.rosenblum@REDACTED Sat Mar 14 04:19:47 2015 From: jim.rosenblum@REDACTED (jim rosenblum) Date: Fri, 13 Mar 2015 23:19:47 -0400 Subject: [erlang-questions] socket_closed_remotely errors with httpc Message-ID: In http://erlang.org/pipermail/erlang-questions/2014-February/077788.html and elsewhere, users observed that httpc would occasionally encounter `{error,socket_closed_remotely}` when querying a web service of some sort. The workaround was to use https 1.0, as opposed to 1.1, which is somewhat of an unsatisfying resolution. I have this (I believe) same problem and have tried to create a minimal example that reproduces the issue using a public url to post a simple JSON body (my 'real' code posts data to a ChicagoBoss server). I am hoping that someone more qualified than I can take this bit of ?research? and maybe figure out this bug? Alternatively, if someone can nudge me in the right direction, I *might* be able to take this further? My code is as follows: -module(httpc_bug). -export([test/0]). test()-> httpc:set_options([{max_keep_alive_length, 0}, {max_pipeline_length, 0}, {max_sessions, 0}]), test_put(0). test_put(N) -> Url = "https://posttestserver.com/post.php", ContentType= "application/json", Body = <<"{\"type\":\"body type\",\"value\":2}">>, Header = [], HttpOptions = [], Options = [], case httpc:request(post, {Url, Header, ContentType, Body}, HttpOptions, Options) of {ok, {{_V, _Cd, _R}, _RespHeader, B }} -> io:format("~p[~p]:~p~n?, [self(), N, B]), test_put(N+1); {error, Reason} -> io:format("~p: died after ~p iterations with: ~p. ~n.", [self(), N, Reason]) end. The problem manifests itself regardless of the options (httpc:setoptions/1) used - or not used. I chose the ones that I did to try to eliminate code-paths involved. A typical run looks like this: Erlang/OTP 17 [erts-6.2] [source-aaaefb3] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.2 (abort with ^G) 1> inets:start(). ok 2> ssl:start(). ok 3> code:load_file(httpc_bug). {module,httpc_bug} 4> httpc_bug:test(1). [<0.15201.0>] <0.15201.0>[0]:"Successfully dumped 0 post variables.\nView it at http://www.posttestserver.com/data/2015/03/13/19.21.45157935823\nPost body was 30 chars long." <0.15201.0>[1]:"Successfully dumped 0 post variables.\nView it at http://www.posttestserver.com/data/2015/03/13/19.21.451784952425\nPost body was 30 chars long." . SNIP <0.15201.0>: died after 102 iterations with: socket_closed_remotely. I just did five runs, four died in under 410 iterations, and the fifth took 809 iterations. By examining the contents of the http_manager__session_db before each call to the httpc:request, I am pretty sure that the flow goes: httpc_manager.erl line 759 ? within a handle_request clause handle_request(Request, State = #state{options = Options}) -> NewRequest = handle_cookies(generate_request_id(Request), State), SessionType = session_type(Options), case select_session(Request#request.method, Request#request.address, Request#request.scheme, SessionType, State) of {ok, HandlerPid} -> *pipeline_or_keep_alive(NewRequest, HandlerPid, State);* . SNIP To httpc_handler.erl line 323 ? within a handle_call where keep_alive requests are handled. I don?t have the sophistication to take this any further. Is this enough information to enable a more qualified individual to pursue this issue. Thoughts much appreciated. JR0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric@REDACTED Sat Mar 14 10:34:45 2015 From: eric@REDACTED (Eric Skoglund) Date: Sat, 14 Mar 2015 10:34:45 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Condu In-Reply-To: <0A3D542F-C398-46ED-A04E-55F022EDE85A@gmail.com> References: <0A3D542F-C398-46ED-A04E-55F022EDE85A@gmail.com> Message-ID: <550400B5.4060002@pagefault.se> > Having said this, I could get behind and even advocate for a CoC if I better > understood what problem we are trying to solve. As I understand it from the discussion the new CoC simply makes the current practices more explicit so that we do have something when and if it is needed. As Fred Hebert stated in the thread: "The idea is not to introduce new rules, it's to make them explicit." // Eric Skoglund From peterhickman386@REDACTED Sat Mar 14 11:05:56 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 10:05:56 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Condu In-Reply-To: <550400B5.4060002@pagefault.se> References: <0A3D542F-C398-46ED-A04E-55F022EDE85A@gmail.com> <550400B5.4060002@pagefault.se> Message-ID: On 14 March 2015 at 09:34, Eric Skoglund wrote: > "The idea is not to introduce new rules, it's to make them explicit." > I was completely unaware that we already had a 74 character limit on our lines. Seems like a new rule to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Mar 14 11:33:52 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Mar 2015 11:33:52 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: Le 13 mars 2015 ? 15:23, Bruce Yinhe a ?crit : > a welcoming, inclusive climate for communication Yet enforces formatting and general posting rules that ostracises any "modern" mail client user that doesn't care about your line-wrapping and your bottom-posting. From peterhickman386@REDACTED Sat Mar 14 13:33:37 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 12:33:37 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: To bring some actual data to this discussion let me present the following. I downloaded all of the mail archive, Broke up the messages and discarded the headers. I then counted the number of lines that were quotes and the length of the non quoted lines. This was with the \n chomped but the footers were included. Here is the data: Processed 83,895 messages The average line length was 29, with a maximum of 9,907. There were a total of 2,980,949 lines checked. The average number of quoted lines per message was 13, the maximum was 1,183. There was a total of 83,894 quoted lines. This does not measure the size of the quoted sections just the total number of lines within a message that were quoted. So a message that quotes 5 lines could be a single 5 lines quote or 5 single line quotes, bear this in mind for the maximum of 1,183. If the total of 2,980,949 lines 149,847 were longer than 74. Which is 5%. 5%!!! OMFG call the mods the end of the world is coming. God save us all. Forgive me father for I have sinned. Are we saying that that 5% was such an imposition that we have to have a rule to stop it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Mar 14 13:59:17 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Mar 2015 13:59:17 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: *Benoit Chesneau* Date: Saturday, March 14, 2015 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct To: Peter Hickman On Saturday, March 14, 2015, Peter Hickman > wrote: > To bring some actual data to this discussion let me present the following. > I downloaded all of the mail archive, Broke up the messages and discarded > the headers. I then counted the number of lines that were quotes and the > length of the non quoted lines. This was with the \n chomped but the > footers were included. Here is the data: > > Processed 83,895 messages > > The average line length was 29, with a maximum of 9,907. There were a > total of 2,980,949 lines checked. > > The average number of quoted lines per message was 13, the maximum was > 1,183. There was a total of 83,894 quoted lines. This does not measure the > size of the quoted sections just the total number of lines within a message > that were quoted. So a message that quotes 5 lines could be a single 5 > lines quote or 5 single line quotes, bear this in mind for the maximum of > 1,183. > > If the total of 2,980,949 lines 149,847 were longer than 74. Which is 5%. > > 5%!!! OMFG call the mods the end of the world is coming. God save us all. > Forgive me father for I have sinned. > > Are we saying that that 5% was such an imposition that we have to have a > rule to stop it? > if we want to welcome new and futures generation most probably yes. Especially since modern mua take care about ti for you. By default they don't break lines neither put at the bottom. Also just have a look in the number of mIls you can receive today that doesn't break lines in the source... -- Sent from my Mobile -- Sent from my Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sat Mar 14 14:39:45 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 14 Mar 2015 09:39:45 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Condu In-Reply-To: References: <0A3D542F-C398-46ED-A04E-55F022EDE85A@gmail.com> <550400B5.4060002@pagefault.se> Message-ID: <20150314133944.GA850@ferdmbp.local> On 03/14, Peter Hickman wrote: > I was completely unaware that we already had a 74 character limit on our > lines. Seems like a new rule to me. Those are more or less recommendations as I understand it. I've been informed some people have been warned/informed privately in the past when their e-mail format was always 'wrong' or unreadable. The CoC is worded in a way that also doesn't mean enforcement will be strict. People in here think like developers a lot in terms of "it is within the rules" or "it is against the rules", leaving little place to toeing the line that we all tend to be fine living with. While the content policy and style policy are mixed in and can be confusing (as pointed out by jlouis), take a look at the wording: 1. *We encourage you to* limit your messages to plain text English. [...] 2. *Please quote* the text you are replying to *in order to ease readability* [...] 3. *Be mindful* of how much text you are quoting. Too much or too little doesn't help. 4. Top posting is discouraged.[...] 5. *Try to break* your lines at around 74 characters. [...] None of this is stone tablets down from the mountain dictating how to do stuff. Those are recommendations of what could be considered reasonable if you want everyone to be able to read you. Hell, for the quoting stuff, you'll notice that over the last day or so, I'll have top-quoted, middle-quoted, and not-quoted in at least one reply to this list, without averse consequences. Probably because things were still readable and no one had to complain. I am sure regulars, moderators, and newcomers will be able to use their judgement to make things readable most of the time, as we nearly almost always have. This isn't a binary all or nothing automated format checker that ends up auto-banning you, this is a set of "please be mindful" recommendations. Compare with the content policy: 1. Be nice to each other. 2. Hateful, hurtful, oppressive, or exclusionary remarks are not tolerated. (Cursing is strongly discouraged, but if you must curse, it may under no circumstances be used to target another user or in a hateful manner). 3. No SPAM, and that's why you have to be subscribed to post.* [...] This one is a lot more direct and you can likely expect harsher enforcement of spammers and people insulting others than people who break 74 characters on their mail client. Regards, Fred. From peterhickman386@REDACTED Sat Mar 14 14:49:12 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 13:49:12 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: Well I have to thank you for proving my points with your post. To me quoting an entire post just to respond to the final line seems to fall into the "too much" quoting category but as we have nothing but a subjective measure for this who is to say that it is. Also the single line that you entered is 293 characters long, a sin that I am also guilty of but then I am actually against these petty rules. Then quoting that post without adding anything at all - let alone useful - is hardly conscientious.? (Takes out his secret policeman's notebook and writes "Benoit Chesneau quotes excessively") I will take your opinion on these things more seriously if you would actually follow the rules yourself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Mar 14 15:01:28 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Mar 2015 15:01:28 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: On Sat, Mar 14, 2015 at 2:49 PM, Peter Hickman < peterhickman386@REDACTED> wrote: > Well I have to thank you for proving my points with your post. To me > quoting an entire post just to respond to the final line seems to fall into > the "too much" quoting category but as we have nothing but a subjective > measure for this who is to say that it is. Also the single line that you > entered is 293 characters long, a sin that I am also guilty of but then I > am actually against these petty rules. > > Then quoting that post without adding anything at all - let alone useful - > is hardly conscientious.? > > (Takes out his secret policeman's notebook and writes "Benoit Chesneau > quotes excessively") > > I will take your opinion on these things more seriously if you would > actually follow the rules yourself. > > I just live with my time and took the mua i had under the hand, ie. inbox on my tablet. I didn't do anything but answering to a mail. If your MUA is not capable to split a line correctly then I can't help you. Even that poor gmail is able to do it. Either mutt that I am using from time to time. One sure thing is that i am not counting the number of characters in a paragraph to split it in 74 chars. I am a human after all. - benoit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhickman386@REDACTED Sat Mar 14 15:11:03 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 14:11:03 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Condu In-Reply-To: <20150314133944.GA850@ferdmbp.local> References: <0A3D542F-C398-46ED-A04E-55F022EDE85A@gmail.com> <550400B5.4060002@pagefault.se> <20150314133944.GA850@ferdmbp.local> Message-ID: On 14 March 2015 at 13:39, Fred Hebert wrote: > On 03/14, Peter Hickman wrote: > > I was completely unaware that we already had a 74 character limit on our > > lines. Seems like a new rule to me. > > Those are more or less recommendations as I understand it. I've been > informed some people have been warned/informed privately in the past > when their e-mail format was always 'wrong' or unreadable. > Ah privately, or as I like to call it "secretly". > The CoC is worded in a way that also doesn't mean enforcement will be > strict. But it can and will be enforced, in secret at that, otherwise there would be no point in even having such rules. Selective enforcement can be seen as "favouritism" or perhaps "bias". Such things lead to discord. > None of this is stone tablets down from the mountain dictating how to do > stuff. Those are recommendations of what could be considered reasonable > if you want everyone to be able to read you. > This is actually the source of the problem, the rules are entirely subjective and down to the whims of someone I do not know who is not held accountable and can enforce them as and when they feel like it without any regard for consistency. > I am sure regulars, moderators, and newcomers will be able to use their > judgement to make things readable most of the time, as we nearly almost > always have. > The judgement of the regulars and newcomers counts for nothing, they do not enforce the rules. Only the judgement of the moderators matter and the rules basically say "make it up as you go along". > Compare with the content policy: > Then let us rewrite the CoC solely around the content policy and discard the rest. I have little issue with the content policy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhickman386@REDACTED Sat Mar 14 15:17:24 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 14:17:24 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: On 14 March 2015 at 14:01, Benoit Chesneau wrote: > If your MUA is not capable to split a line correctly then I can't help > you. Even that poor gmail is able to do it. > Odd that because it is gmail that I am using and that line went the full length of my monitor - I have a large monitor. So blaming the MUA is not going to work here, to make the lines break on 74 characters you have to format it yourself rather than blame the recipient. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harit.subscriptions@REDACTED Sat Mar 14 15:57:22 2015 From: harit.subscriptions@REDACTED (Harit Himanshu) Date: Sat, 14 Mar 2015 07:57:22 -0700 Subject: [erlang-questions] Modeling Recursion into Tail Recursion Message-ID: Hello I was trying to work through finding fibonacci number 10 days ago and my first attempt looked like -module(solution). -export([main/0, fib/2]). main() -> {ok, [N]} = io:fread("", "~d"), io:format("~p~n", [fib(N, maps:new())]). fib(1, _) -> 0; fib(2, _) -> 1; fib(N, Map) -> case maps:find(N, Map) of {ok, Value} -> Value; error -> fib(N -1, Map) + fib(N-2, Map) end. Then I realized that tho is going to be very inefficient to store all values. Plus for large numbers the recursion will create lot more stacks. no no! This morning I spent some time to learn the concept of Tail Recursion and re-tried the same problem again with following code -module(solution). -export([main/0]). main() -> {ok, [N]} = io:fread("", "~d"), io:format("~p~n", [fib(N, 0, 1)]). fib(1, Prev, _) -> Prev; fib(N, Prev, Next) when N > 0 -> fib(N-1, Next, Prev + Next). I wanted to check through the community to learn about better ways to solve the problem. *Question* 1. Since the concept for tail recursion is new to me I specially wanted to ask that how could I model my thinking to turn recursive functions into tail-recursive functions? 2. Can we turn every recursive function into tail-recursive? If no, how to identify? 3. Any other valuable recommendation based on your learnings? Thank you + Harit Himanshu -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Mar 14 16:15:13 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Mar 2015 16:15:13 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: Le 14 mars 2015 ? 15:17, Peter Hickman a ?crit : > Odd that because it is gmail that I am using and that line went the full length of my monitor - I have a large monitor. So blaming the MUA is not going to work here, to make the lines break on 74 characters you have to format it yourself rather than blame the recipient. You do know that your own mails aren't wrapped, right? And that it is GMail's fault for providing a bad UI? Trying to enforce rules that go against most "modern" MUAs is not being inclusive. From peterhickman386@REDACTED Sat Mar 14 16:43:19 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 15:43:19 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: Anthony My point was that Benoit posted a 293 character line while saying: > If your MUA is not capable to split a line correctly then I can't help you. He then goes on to say: > Even that poor gmail is able to do it. The problem here is that my MUA is gmail, the very MUA that Benoit says can split a line correctly but is not doing so. His statement is therefore false. Trying to blame my MUA for not correctly formatting his overlong line is arse about face. The formatting needs to be made by the author not the recipient. The CoC rules are about how the author should act not the recipient. Thus Benoit as the author of his own post should format his post to conform to the CoC rather than blame the recipients MUA for not abiding with the CoC. On 14 March 2015 at 15:15, Anthony Ramine wrote: > You do know that your own mails aren't wrapped, right? And that it is > GMail's fault for providing a bad UI? > I actually mentioned this myself, did you not read it? "Also the single line that you entered is 293 characters long, a sin that I am also guilty of but then I am actually against these petty rules." > Trying to enforce rules that go against most "modern" MUAs is not being > inclusive. > What I have been saying is that these rules are bad but if someone wants to argue that they are necessary then I would at least expect them to follow the rules that they say are necessary. I don't believe that I am asking too much in this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Mar 14 16:53:30 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Mar 2015 16:53:30 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <4C14C4C5-FCD6-4455-8996-8A6E192C801C@gmail.com> Le 14 mars 2015 ? 16:43, Peter Hickman a ?crit : > I don't believe that I am asking too much in this. Sorry, misread you. I'll blame neither the MUA nor recipient, but urticaria. From peterhickman386@REDACTED Sat Mar 14 17:27:18 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 16:27:18 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <4C14C4C5-FCD6-4455-8996-8A6E192C801C@gmail.com> References: <4C14C4C5-FCD6-4455-8996-8A6E192C801C@gmail.com> Message-ID: No problem. On 14 March 2015 at 15:53, Anthony Ramine wrote: > Le 14 mars 2015 ? 16:43, Peter Hickman a > ?crit : > > > I don't believe that I am asking too much in this. > > Sorry, misread you. I'll blame neither the MUA nor recipient, but > urticaria. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Mar 14 17:33:21 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Mar 2015 16:33:21 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: On Sat, Mar 14, 2015 at 4:43 PM Peter Hickman < peterhickman386@REDACTED> wrote: > Anthony > > My point was that Benoit posted a 293 character line while saying: > > > If your MUA is not capable to split a line correctly then I can't help > you. > > He then goes on to say: > > > Even that poor gmail is able to do it. > > The problem here is that my MUA is gmail, the very MUA that Benoit says > can split a line correctly but is not doing so. His statement is therefore > false. Trying to blame my MUA for not correctly formatting his overlong > line is arse about face. The formatting needs to be made by the author not > the recipient. The CoC rules are about how the author should act not the > recipient. Thus Benoit as the author of his own post should format his post > to conform to the CoC rather than blame the recipients MUA for not abiding > with the CoC. > Well it is, of course i am not that people that use all the windows in full screen so I find the mail perfectly readable and never noticed. I also didn't noticed your mail wasn't wrapped because ... I am living with my time, and... read it on a 11" screen. You will note that there are no way to force wrapping in gmail, neither in Mail.app, maybe there is in thunderbird or outlook ( I didn't find it but i may be just blind). The way people are generally do since the mail exists is to configure their mua or editor used for sending a mail to wrap these messages (just like in code). This is not possible in some mua, And curiously posting at the bottom not the default anymore in modern mua (while it was in some them some years ago). Then the questions are: - Do you want to force people to wrap their mail (and count chars) manually? Do you think people will really lose their time to do it? - Why do you think bottom posting is not the default now? And why MUAs don't enforce the column limit anymore? ( I actually find this question quite interesting). To come back to that COC, I am not really fond to have one, i would just skip it. But if some really want to have one then I would just focus on the interactions, the conduct between people not to "encourage" people to adopt a style. (which means forcing over the time like shows this thread) - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Mar 14 17:34:59 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Mar 2015 17:34:59 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: On Sat, Mar 14, 2015 at 4:43 PM Peter Hickman < peterhickman386@REDACTED> wrote: > Anthony > > My point was that Benoit posted a 293 character line while saying: > > > If your MUA is not capable to split a line correctly then I can't help > you. > > He then goes on to say: > > > Even that poor gmail is able to do it. > > The problem here is that my MUA is gmail, the very MUA that Benoit says > can split a line correctly but is not doing so. His statement is therefore > false. Trying to blame my MUA for not correctly formatting his overlong > line is arse about face. The formatting needs to be made by the author not > the recipient. The CoC rules are about how the author should act not the > recipient. Thus Benoit as the author of his own post should format his post > to conform to the CoC rather than blame the recipients MUA for not abiding > with the CoC. > Well it is, of course i am not that people that use all the windows in full screen so I find the mail perfectly readable and never noticed. I also didn't noticed your mail wasn't wrapped because ... I am living with my time, and... read it on a 11" screen. You will note that there are no way to force wrapping in gmail, neither in Mail.app, maybe there is in thunderbird or outlook ( I didn't find it but i may be just blind). The way people are generally do since the mail exists is to configure their mua or editor used for sending a mail to wrap these messages (just like in code). This is not possible in some mua, And curiously posting at the bottom not the default anymore in modern mua (while it was in some them some years ago). Then the questions are: - Do you want to force people to wrap their mail (and count chars) manually? Do you think people will really lose their time to do it? - Why do you think bottom posting is not the default now? And with mua don't enforce the column limit anymore? ( I actually find this question quite interesting). To come back to that COC, I am not really fond to have one, i would just skip it. But if some really want to have one then I would just focus on the interactions, the conduct between people not to "encourage" people to adopt a style. (which means forcing over the time like shows this thread) - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhickman386@REDACTED Sat Mar 14 17:50:45 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sat, 14 Mar 2015 16:50:45 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: Personally I would drop everything except the content policy. The content policy is fine, the rest of the CoC is unnecessary. Lets have a content policy and then discuss the why and hows of a "style guide". But I believe that a style guide is completely unnecessary. Line length, I don't care Top posting/bottom posting, I don't care But I do care if someone is going to try and impose them on me. This is the sort of thing that always gets my back up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric@REDACTED Sat Mar 14 17:55:16 2015 From: eric@REDACTED (Eric Skoglund) Date: Sat, 14 Mar 2015 17:55:16 +0100 Subject: [erlang-questions] Modeling Recursion into Tail Recursion In-Reply-To: References: Message-ID: <20150314165516.GA1159@arch.lan> On Sat, Mar 14, 2015 at 07:57:22AM -0700, Harit Himanshu wrote: > *Question* > > 1. Since the concept for tail recursion is new to me I specially wanted > to ask that how could I model my thinking to turn recursive functions into > tail-recursive functions? > 2. Can we turn every recursive function into tail-recursive? If no, how > to identify? One resource that helped me a lot was the recursion chapter of learn you some erlang: http://learnyousomeerlang.com/recursion#hello-recursion As for the second question I'm not 100% sure I'm remembering this correctly but using continuation-passing-style you could express every recursive function with tail-recursion. // Eric Skoglund From ingela.andin@REDACTED Sat Mar 14 18:08:06 2015 From: ingela.andin@REDACTED (Ingela Andin) Date: Sat, 14 Mar 2015 18:08:06 +0100 Subject: [erlang-questions] Fwd: Figuring out proper ssl certificate settings with 17.3 In-Reply-To: <12631081.mHgd8Kso8B@moltowork> References: <4306941.X6676PlrAe@moltowork> <2200058.cD7JN7KKEC@moltowork> <12631081.mHgd8Kso8B@moltowork> Message-ID: Hi! To answer a previous question, in the thread. The X509 certificate path validation is done identical on the server and the client side, however that does not mean that the CA inputs are used only for this reason. The Server will always send a cert, but the client will only send one if it was requested by the server. Also the server may send information in its request to inform the client of which certs it supports. 2015-02-20 13:44 GMT+01:00 Vincent de Phily < vincent.dephily@REDACTED>: > On Thursday 19 February 2015 18:43:26 Vincent de Phily wrote: > > On Thursday 22 January 2015 21:45:08 Ingela Andin wrote: > > > If you want to handle > > > incorrect clients by building the chain to the client certificate on > the > > > server side , if possible, you need to do that in the verify_fun when > it > > > fails and then call public_key:pkix_path_validation again with the > chain > > > that you built. > > > > I didn't try this yet, but I verified that > > > > > {partial_chain, fun(CAs) -> {trusted_ca,hd(CAs)} end} > > > > "solves" my issue but is basically a verify_none. It seems there's some > > functionality overlap between partial_chain and verify_fun, but I'm not > 100% > > sure when to use which. > > FWIW, I managed to get the behaviour I expect (can you spot a bug ?) using > either verify_fun or partial_chain: > > Verif = fun(Cert,{bad_cert, _}, _) -> > case public_key:pkix_path_validation(TrustedCA,[Cert],[]) > of > {ok, _} -> {valid, P}; > {error, Reason} -> {fail, Reason} > end; > (_, {extension, Ex}, _) -> > {unknown, []}; > (_, valid, _) -> > {valid, []}; > (_, valid_peer, _) -> > {valid, []} > end, > I would match on the unknown_ca atom too. > Partial = fun(Chain) -> > case public_key:pkix_path_validation(TrustedCA,Chain,[]) > of > {ok, _} -> {trusted_ca,hd(Chain)}; > {error, Reason} -> Reason > end > end, > > Connecting with > {fail_if_no_peer_cert, true}, > {verify, verify_peer}, > {cert, MyCert}, > {key, MyKey}, > {cacerts, [TrustedCA]} > and either > {verify_fun, {Verif,[]}} > or > {partial_chain, Partial} > Same config for both the client and the server, only the values of > TrustedCA > and MyCert/MyKey change. > > At this stage, I'm still unsure wether using verify_fun or partial_chain > makes > more sense (or is faster). > > There is a semantical difference, the verify_fun is for customising the X509-certificate path validation, the partial chain option is for disregarding certs higher up in the chain, see also below. > > I'd like OTP to do the "peer-sent cert chain is signed by one of the > localy- > > trusted CAs" step for me. I realize that I could do it myself using the > > public_key module, but I find it very surprising that my usecase would be > > so unusual that it isn't supported out of the box. A peer that sends the > > smallest chain that can be verified by the other peer isn't "incorrect". > > Sending only the peer certificate and not sending intermediate CAs breaks the TLS protocol, I would not call it correct. The partial chain option was introduced to let you skip validation steps of CAs that you do not care about. If you get a chain Root --> A -> B -> C -> Peer and you for some reason have decided that you trust B you can run the path_validation algorithm with B as trusted ( B becomes the root in practice). In the partial chain fun you are responsible to check that the cert you select as root is one that you trust. > These concerns are still valid. If feels strange that my version of > verify_fun > does something different than OTP's version. > > Why is that strange? The verify_fun is there so that you can customise your verification. This of course gives you some responsibility too, of getting it right! You can both add application specific checks and change the default behaviour any way you like, and of course take the consequences of doing so. Regards Ingela Erlang/OTP Team - Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sat Mar 14 18:42:50 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 14 Mar 2015 13:42:50 -0400 Subject: [erlang-questions] Modeling Recursion into Tail Recursion In-Reply-To: References: Message-ID: <20150314174249.GE850@ferdmbp.local> On 03/14, Harit Himanshu wrote: > 1. Since the concept for tail recursion is new to me I specially wanted > to ask that how could I model my thinking to turn recursive functions into > tail-recursive functions? A tail-recursive function often does so by taking the call stack, and turning it into an argument. The simplest example for this is a function like `sum', defined recursively as: sum([]) -> 0; sum([H|T]) -> H + sum(T). To make it tail-recursive, observe how it would expand, say with [1,2,3]: sum([1,2,3]) 1 + sum([2,3]) 1 + 2 + sum([3]) 1 + 2 + 3 + sum([]) 1 + 2 + 3 + 0 6 To turn it tail recursive, let's take all of these 'waiting' additions and move them as an argument: sum(List) -> sum(List, 0). sum([], Sum) -> Sum; sum([H|T], Sum) -> sum(T, H + Sum). You will still find all the same information in either. The difference is that instead of implictly storing your additions in the call stack (1 + ), you calculate it at every level and reduce it slowly: sum([1,2,3]) sum([1,2,3], 0) sum([2,3], 1) % 1+0 sum([3], 3) % 3+1 <=> 3+1+0 sum([], 6) % 3+3 <=> 3+3+1+0 6 The same computation takes place, but we moved it implictly. It's even more obvious with a 'map' function: map(_, []) -> []; map(F, [H|T]) -> [F(H) | map(F, T)]. Which expands as: F = fun(X) -> 2*X end map(F, [1,2,3]) [2 | map(F, [2,3])] [2 | [4 | map(F, [3])]] [2 | [4 | [6 | map(F, [])]]] [2 | [4 | [6 | []]]] [2,4,6] Compared to the tail recursive: map(F, List) -> map(F, List, []). map(_, [], Acc) -> lists:reverse(Acc); map(F, [H|T], Acc) -> map(F, T, [f(H)|Acc]). Expanding to: F = fun(X) -> 2*X end map(F, [1,2,3]) map(F, [1,3,3], []) map(F, [2,3], [2]) map(F, [3], [4,2]) map(F, [], [6,4,2]) lists:reverse([6,4,2]) [2,4,6] You can see the stack growing and the list getting smaller in the recursive function. You can see the same happening with the tail-recursive function. The reverse step is optional (you could use [A]++Tail, but it's less efficient), but the interesting part is really that you take the implicit stack and make it explicit. > 2. Can we turn every recursive function into tail-recursive? If no, how > to identify? I believe you can. I don't have proper enough chops in computer science to assert so or present a formal proof, but generally, any recursive function can be made iterative (work in a while loop), and pretty much all while loops are easy to convert into a tail-recursive functions. I'll let anyone with proper computer science knowledge or memory answer this one for me, but really, a good question to ask is 'should you?' I assert that you shouldn't convert all functions to tail recursive ones. For example, tree traversal is expressed extremely simply with recursion. Take the tree: A / \ B C / \ D E The following function: traverse({leaf, L}) -> show(L); traverse({tree, Value, Left, Right}) -> show(Value), traverse(Left), traverse(Right). will display nodes of the tree in the order A -> B -> D -> E -> C. Change it for: traverse({leaf, L}) -> show(L); traverse({tree, Value, Left, Right}) -> traverse(Left), show(Value), traverse(Right). And you get D -> B -> E -> A -> C. Change it for: traverse({leaf, L}) -> show(L); traverse({tree, Value, Left, Right}) -> traverse(Left), traverse(Right), show(Value). And now you have D -> E -> B -> C -> A. Expressing these traversals tail-recursively is much harder. But it's what you need to do if you want to print A -> B -> C -> D -> E (level-order): traverse(Tree) -> traverse1([Tree]). traverse1([]) -> done; traverse1([{leaf, L} | T]) -> show(L), traverse1(T); traverse1([{node,V,L,R} | T]) -> show(V), traverse1(T++[L,R]). So now we need to take the upcoming recursions, put them in a queue, and traverse them iteratively, because digging through the tree is more trouble. This can be done with *all* traversals, but really, if you can avoid them, maybe you should. In cases like 'map', it's often more efficient to write the function recursively than tail-recursively (you save a reversal, which is a whole traversal, but garbage-collection can be tricky! See http://ferd.ca/erlang-s-tail-recursion-is-not-a-silver-bullet.html) > 3. Any other valuable recommendation based on your learnings? > Practice a lot. You may have ease starting to think of your tail-recursive functions as while loops: duplicate(N, Term) -> % this is not real code while N > 0 -> List = [Term|List], N = N-1 end, List. Which is equivalent to: duplicate(N, Term) -> duplicate(N, Term, []). duplicate(0, _, List) -> List; duplicate(N, Term, List) when N > 0 -> duplicate(N-1, Term, [Term|List]). See the 'N-1' is there in both, the 'N > 0' also (though it can be implicit), and same for [Term|List], and the final, 'List' to be returned. Of course the same is there: duplicate(0,_) -> []; duplicate(N,Term) when N > 0 -> [Term|duplicate(N-1,Term)]. Eventually, you'll stop thinking in terms of 'while loops' to be translated in functions, to the opposite: think in functions to be exploded into while loops. Regards, Fred. From lcastro@REDACTED Sat Mar 14 20:12:58 2015 From: lcastro@REDACTED (Laura M. Castro) Date: Sat, 14 Mar 2015 20:12:58 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: > If I were to critique something here, it would be that the current CoC mixes > text on social interaction[-1] (that is, how to behave with respect to other > people) from mailing list etiquette (how to quote, how to make older mail > readers happy[0]). I think this is a very good, constructive point. I agree. Also, from other emails in this thread, it seems to me that most of the criticisms are directed towards the second part, so perhaps splitting the two, as Jesper suggests, will not only benefit us as a group if/when our activity extends to other areas/tools (i.e. the bug tracker that he mentions), but also help us to reach consensus. From jim.rosenblum@REDACTED Sat Mar 14 22:14:30 2015 From: jim.rosenblum@REDACTED (jim rosenblum) Date: Sat, 14 Mar 2015 17:14:30 -0400 Subject: [erlang-questions] socket_closed_remotely errors with httpc Message-ID: New work around... > httpc:set_options([{max_keep_alive_length, 0}, > > {max_pipeline_length, 0}, > > {max_sessions, 0}]), > > > The problem manifests itself regardless of the options > (httpc:setoptions/1) used - or not used. I chose the > ones that I did to try to eliminate code-paths involved. > The problem disappeared when I add {"connection", "close"} to the header which: 1) reinforces my belief that the offending code path is the one outlined in my original post; and, 2) gives an alternative to backing down to http 1.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Sun Mar 15 04:26:12 2015 From: sean@REDACTED (Sean Cribbs) Date: Sat, 14 Mar 2015 22:26:12 -0500 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: On Fri, Mar 13, 2015 at 9:23 AM, Bruce Yinhe wrote: > This code is not exhaustive or complete. It serves to distill our common > understanding of a collaborative, shared environment and goals. We expect > it to be followed in spirit as much as in the letter. > > http://www.erlang.org/download/erlang_org_code_of_conduct.txt > > Since I went on a rant about this on Twitter, it is only appropriate that I reply here in long form. I believe the guidelines are inadequate. As others have mentioned, while there are many lines addressing formatting of messages and such, there are very few social guidelines. If we want the Erlang community to be one that welcomes newcomers of all types, appreciates the contributions of the non-privileged, and fosters goodwill, we need to be more specific than "Be nice to each other". At minimum, I would like to see affordances for people -- especially those who are not in the majority -- who have grievances, means to report and act on violations of the CoC, and how those in authority are affected by and held to the CoC. For further reading from people who are way more informed and eloquent on the subject, and a firsthand experience of a community that has established a CoC, I suggest the links below. http://www.ashedryden.com/blog/codes-of-conduct-101-faq#cocfaqnegative http://www.sheldon-hess.org/coral/2013/08/wheatons-law-is-not-enough-and-damn-it-you-are-not-neutral/ https://plus.google.com/+HannahGrimm/posts/5517czLTefa -- Sean Cribbs Sr. Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From timbutterfield@REDACTED Sun Mar 15 05:42:28 2015 From: timbutterfield@REDACTED (Tim Butterfield) Date: Sat, 14 Mar 2015 21:42:28 -0700 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: On Sat, Mar 14, 2015 at 8:26 PM, Sean Cribbs wrote: > If we want the Erlang community to be one that welcomes newcomers of all > types, appreciates the contributions of the non-privileged, and fosters > goodwill, we need to be more specific than "Be nice to each other". At > minimum, I would like to see affordances for people -- especially those who > are not in the majority -- who have grievances, means to report and act on > violations of the CoC, and how those in authority are affected by and held > to the CoC. I am a recent Erlang user. Recently, I took a look at the contents of this list via the Google Groups interface. The first thread I read was about the CoC. My first inclination was not to feel welcomed, but to flee. No imposition is welcoming, especially ones requiring a change in default MUA behavior. I decided to give the group a chance to see how this plays out. Since welcoming new users was intended, the following is how this new member feels about this. As for being nice, it might be sufficient. The http://www.c-brats.com/ forum (about C-Dory boats) has this statement: "No Rules - Just be nice!" That was the most welcoming wording I have seen. For them, this has been sufficient for many years. That forum was created because the prior forum had too many rules. Many members of the old forum moved over to the new one and the prior forum is now gone. Rules may be necessary, though I do not generally consider them welcoming. Please do not consider the necessity as a welcome. I have also been other places where necessary rules have been imposed due to behaviors. Rules equating to 'be nice' do not trouble me, as I try to be by default. Wording matters. I appreciated the word 'discouraged' on the item about top posting, though this conflicts with it being an offense for which one can be banned. Something one can be banned for is prohibited, not just discouraged. It is similar for 'Try' for line length, which can be effectively impossible as not all MUA are conducive to this. I use gmail. I'm not sure anything other than manually counting characters on every line is possible, especially with the default proportional font. If necessary, I could use HTML emails just so I could use Courier and count characters more easily. I may accidentally leave in the character ruler line used for checking line length. My guess is that would be worse and not better for those who prefer 74 characters lines. Be careful what is required. You might get it along with the side effects. The text in the second paragraph of the CoC seems directed at those in a moderator role. Or, is the intent that anyone can decide for themselves to act as moderator. I'm not sure I want to fit in that category, especially as a new member. Also, is it intended that these discussions of infraction be public instead of private? Reading that text as a new member makes me wonder whether the CoC is for general members or for moderators. Overall, it would be nice to know the difference between policy/prohibitions for which one can be banned and simple preference. The current CoC seems to confuse these, at least, I hope it is just confusion. I would not want to risk being banned simply because I forgot to override a controllable MUA behavior (top posting) once too often. Tim From ok@REDACTED Sun Mar 15 09:28:46 2015 From: ok@REDACTED (ok@REDACTED) Date: Sun, 15 Mar 2015 21:28:46 +1300 Subject: [erlang-questions] Modeling Recursion into Tail Recursion In-Reply-To: <20150314165516.GA1159@arch.lan> References: <20150314165516.GA1159@arch.lan> Message-ID: > On Sat, Mar 14, 2015 at 07:57:22AM -0700, Harit Himanshu wrote: >> *Question* >> 2. Can we turn every recursive function into tail-recursive? If no, >> how >> to identify? > As for the second question I'm not 100% sure I'm remembering this > correctly but using continuation-passing-style you could express every > recursive function with tail-recursion. Yes you can but it's not USEFUL to do so. Put very briefly, CPS style means passing an extra argument to each function, called a "continuation". This is a function that expresses "what to do next". Basically, it *is* the recursion stack you would otherwise have had, disguised as a function. There are plenty of good reasons to do this, such as situations where a function needs more than one continuation, or you want to simulate long-distance return, or you want a function that can return more than once, e.g., to do backtracking. But using CPS in order to use tail recursion is like cutting slots in nails so you can use a screwdriver on them. From drormein@REDACTED Sun Mar 15 09:58:51 2015 From: drormein@REDACTED (Dror Mein) Date: Sun, 15 Mar 2015 08:58:51 +0000 (UTC) Subject: [erlang-questions] process suspended on bif_return_trap/1 In-Reply-To: References: Message-ID: <73642888.6899503.1426409931092.JavaMail.yahoo@mail.yahoo.com> Thank you Jesper,the message is sent inside my node to a very busy process. Does it mean that the busy process has a "full buffer"?How do you guard from such a thing on a regular gen_server?The message queue was flushed out once I sent (from shell) a bang to a completely different process.That got me thinking that perhaps the problem was somehow caused by the fact that I had dbg:trace on the sending process, plus was running with observer on the node.Is it plausable?? On Thursday, March 12, 2015 8:49 PM, Jesper Louis Andersen wrote: The bif_return_trap/1 is a trampoline function used by bifs that suspend in order to graft them onto the normal interpreter later on. It's purpose is to make the BIF look like a normal function. Processes might get suspended on a send for two reasons: * The process you are looking for is in another castle (read: on a foreign node). If the TCP buffer for the distribution protocol is full the process gets suspend until there is room.* The port you are sending to is currently busy. What this means depends on the type of port, but usually this is a full buffer of some kind as well. On Thu, Mar 12, 2015 at 10:52 AM, Dror Mein wrote: hi all,I have a gen_server process who is suspended. it's stack trace has him currently trying to send a message with a bang.?my first question is why? why a process gets suspended? current function: erlang:bif_return_trap/1the destination process is ok.second question: how do you guard from a situation like this? Thanks,Dror _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sun Mar 15 12:22:02 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 15 Mar 2015 12:22:02 +0100 Subject: [erlang-questions] process suspended on bif_return_trap/1 In-Reply-To: <73642888.6899503.1426409931092.JavaMail.yahoo@mail.yahoo.com> References: <73642888.6899503.1426409931092.JavaMail.yahoo@mail.yahoo.com> Message-ID: On Sun, Mar 15, 2015 at 9:58 AM, Dror Mein wrote: > Does it mean that the busy process has a "full buffer"? Hard to say. If process P has a large mailbox, it is more expensive in reductions to send a message to P. But I'm not sure this is what you are seeing here. The guard against such things are to employ some kind of flow control scheme between processes. Usually either credit-based flow or window-based flow. Maybe the tracing interacts, I honestly do not know. We are in read-the-source to understand anyway at this point. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Mar 15 15:37:53 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 15 Mar 2015 15:37:53 +0100 Subject: [erlang-questions] Code of Formatting Message-ID: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> Given people seem to think we ought to have a code of conduct, could we also get a code of formatting? Could the OTP sources finally enter the 21th century and stop ostracising people not using Emacs or Vim? I'm too tired of having to suffer GNU-style indentation with mixed spaces and tabs. From zxq9@REDACTED Sun Mar 15 15:46:54 2015 From: zxq9@REDACTED (zxq9) Date: Sun, 15 Mar 2015 23:46:54 +0900 Subject: [erlang-questions] Code of Formatting In-Reply-To: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> Message-ID: <5189168.lxQs2RnI8c@changa> On 2015?3?15? ??? 15:37:53 Anthony Ramine wrote: > Given people seem to think we ought to have a code of conduct, could we also > get a code of formatting? Could the OTP sources finally enter the 21th > century and stop ostracising people not using Emacs or Vim? > > I'm too tired of having to suffer GNU-style indentation with mixed spaces > and tabs. HERESY! The land of intermonkey communication must be regulated at all costs -- I mean, THEY ARE FRIGGIN MONKEYS! If they overrun 74 characters per line... who knows? A poo-flinging line-overrun party may easily ensue! The land of actual code that makes the whole party possible is, you know, like your opinion, man. -Craig PS: I forgot... was sarcasm made verboten in the CoC? I couldn't tell, since the last thread seemed to be mostly done for the lulz. From valentin@REDACTED Sun Mar 15 16:16:17 2015 From: valentin@REDACTED (Valentin Micic) Date: Sun, 15 Mar 2015 17:16:17 +0200 Subject: [erlang-questions] Code of Formatting In-Reply-To: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> Message-ID: How about this: If you think that reading such code may be of some benefit to you (e.g. help you learn something new), then, I suppose, "fixing" indentation problems may even be worth it (and you should quit complaining about it). Otherwise, assume that the author had no intention for you to read his code, and move on. V/ On 15 Mar 2015, at 4:37 PM, Anthony Ramine wrote: > Given people seem to think we ought to have a code of conduct, could we also get a code of formatting? Could the OTP sources finally enter the 21th century and stop ostracising people not using Emacs or Vim? > > I'm too tired of having to suffer GNU-style indentation with mixed spaces and tabs. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Sun Mar 15 16:46:00 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 15 Mar 2015 16:46:00 +0100 Subject: [erlang-questions] Code of Formatting In-Reply-To: References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> Message-ID: Le 15 mars 2015 ? 16:16, Valentin Micic a ?crit : > How about this: > If you think that reading such code may be of some benefit to you (e.g. help you learn something new), then, I suppose, "fixing" indentation problems may even be worth it (and you should quit complaining about it). > Otherwise, assume that the author had no intention for you to read his code, and move on. > > V/ How about this: I'm not reading code I'm contributing to it enough to get an award. I rebase code that I wrote against a refactoring of mine that was merged back into OTP, and I have conflicts because someone touched it afterwards in a dubious fashion and reintroduced tabs in it. Also, you top-posted, such outrage, wow offense. From eric.pailleau@REDACTED Sun Mar 15 18:41:33 2015 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Sun, 15 Mar 2015 18:41:33 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct Message-ID: <90ef9959096d330c6f429258952e6689@mwinf5d54.me-wanadoo.net> Hello, CoC is a strange name for something that looks to suck everybody. Humour.Le 15 mars 2015 05:42, Tim Butterfield a ?crit : > > On Sat, Mar 14, 2015 at 8:26 PM, Sean Cribbs wrote: > > If we want the Erlang community to be one that welcomes newcomers of all > > types, appreciates the contributions of the non-privileged, and fosters > > goodwill, we need to be more specific than "Be nice to each other". At > > minimum, I would like to see affordances for people -- especially those who > > are not in the majority -- who have grievances, means to report and act on > > violations of the CoC, and how those in authority are affected by and held > > to the CoC. > > I am a recent Erlang user.? Recently, I took a look at the contents of > this list via the Google Groups interface.? The first thread I read > was about the CoC.? My first inclination was not to feel welcomed, but > to flee.? No imposition is welcoming, especially ones requiring a > change in default MUA behavior.? I decided to give the group a chance > to see how this plays out.? Since welcoming new users was intended, > the following is how this new member feels about this. > > As for being nice, it might be sufficient.? The > http://www.c-brats.com/ forum (about C-Dory boats) has this statement: > "No Rules - Just be nice!"? That was the most welcoming wording I have > seen.? For them, this has been sufficient for many years.? That forum > was created because the prior forum had too many rules.? Many members > of the old forum moved over to the new one and the prior forum is now > gone.? Rules may be necessary, though I do not generally consider them > welcoming.? Please do not consider the necessity as a welcome.? I have > also been other places where necessary rules have been imposed due to > behaviors.? Rules equating to 'be nice' do not trouble me, as I try to > be by default. > > Wording matters.? I appreciated the word 'discouraged' on the item > about top posting, though this conflicts with it being an offense for > which one can be banned.? Something one can be banned for is > prohibited, not just discouraged.? It is similar for 'Try' for line > length, which can be effectively impossible as not all MUA are > conducive to this.? I use gmail.? I'm not sure anything other than > manually counting characters on every line is possible, especially > with the default proportional font. If necessary, I could use HTML > emails just so I could use Courier and count characters more easily. > I may accidentally leave in the character ruler line used for checking > line length.? My guess is that would be worse and not better for those > who prefer 74 characters lines.? Be careful what is required.? You > might get it along with the side effects. > > The text in the second paragraph of the CoC seems directed at those in > a moderator role.? Or, is the intent that anyone can decide for > themselves to act as moderator.? I'm not sure I want to fit in that > category, especially as a new member.? Also, is it intended that these > discussions of infraction be public instead of private?? Reading that > text as a new member makes me wonder whether the CoC is for general > members or for moderators. > > Overall, it would be nice to know the difference between > policy/prohibitions for which one can be banned and simple preference. > The current CoC seems to confuse these, at least, I hope it is just > confusion.? I would not want to risk being banned simply because I > forgot to override a controllable MUA behavior (top posting) once too > often. > > Tim > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From valentin@REDACTED Sun Mar 15 18:56:12 2015 From: valentin@REDACTED (Valentin Micic) Date: Sun, 15 Mar 2015 19:56:12 +0200 Subject: [erlang-questions] Code of Formatting In-Reply-To: References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> Message-ID: <517FC917-343E-4633-841A-01061188949D@pixie.co.za> I do not understand why did my post offend you. I've just shared what works for me, assuming that it may work for you too. From your original post I could not deduce (and I think that no reasonable man could have) the nature of the problem, so I assumed that your "suffering" was related to the code reading. But now that you've mentioned contributing (and award winning) -- should that really entitle you to prescribe how others must write their code -- even the code that you've contributed; for you may have a reasonable expectation for a recognition (e.g. another award); however, I would disagree that this entitle you to expect others to use a particular editor/IDE (just to make it clear -- I am not trying to defend Emacs or Vim, nor am I using them). V/ On 15 Mar 2015, at 5:46 PM, Anthony Ramine wrote: > Le 15 mars 2015 ? 16:16, Valentin Micic a ?crit : > >> How about this: >> If you think that reading such code may be of some benefit to you (e.g. help you learn something new), then, I suppose, "fixing" indentation problems may even be worth it (and you should quit complaining about it). >> Otherwise, assume that the author had no intention for you to read his code, and move on. >> >> V/ > > How about this: > > I'm not reading code I'm contributing to it enough to get an award. I rebase code that I wrote against a refactoring of mine that was merged back into OTP, and I have conflicts because someone touched it afterwards in a dubious fashion and reintroduced tabs in it. > > Also, you top-posted, such outrage, wow offense. From g@REDACTED Sun Mar 15 19:21:10 2015 From: g@REDACTED (Garrett Smith) Date: Sun, 15 Mar 2015 13:21:10 -0500 Subject: [erlang-questions] Code of Formatting In-Reply-To: References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> Message-ID: On Sun, Mar 15, 2015 at 10:46 AM, Anthony Ramine wrote: > I rebase code that I wrote against a refactoring of mine that was merged back into OTP, and I have conflicts because someone touched it afterwards in a dubious fashion and reintroduced tabs in it. This is incredibly frustrating and a completely avoidable problem. +1 for Anthony's suggestion. It's a baseline for encouraging contributions (along with other things, such as a public issues list). It doesn't seem hard and it would send more positive signals that there's progress in the community building efforts. Garrett From n.oxyde@REDACTED Sun Mar 15 19:43:04 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 15 Mar 2015 19:43:04 +0100 Subject: [erlang-questions] Code of Formatting In-Reply-To: <517FC917-343E-4633-841A-01061188949D@pixie.co.za> References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> <517FC917-343E-4633-841A-01061188949D@pixie.co.za> Message-ID: <196FC375-8444-4643-A3CC-0CE3889B9159@gmail.com> Le 15 mars 2015 ? 18:56, Valentin Micic a ?crit : > I do not understand why did my post offend you. > I've just shared what works for me, assuming that it may work for you too. > > From your original post I could not deduce (and I think that no reasonable man could have) the nature of the problem, so I assumed that your "suffering" was related to the code reading. > > But now that you've mentioned contributing (and award winning) -- should that really entitle you to prescribe how others must write their code -- even the code that you've contributed; for you may have a reasonable expectation for a recognition (e.g. another award); however, I would disagree that this entitle you to expect others to use a particular editor/IDE (just to make it clear -- I am not trying to defend Emacs or Vim, nor am I using them). You assume my mail is about code reading. It's not. The OTP code with a tab width of 8 is readable. Now if you had known what are the current untold indentation rules of the code base, maybe you would have restrained yourself from telling me to just "fix" it (note your use of scare quotes as if it wasn't an actual problem) with a patch. I know that I can patch things when they are broken or need to be improved, thank you. I'm not entitled to prescribe how others must write their code, but I feel at least entitled to not be told to just write a patch about something that is outside of my sphere of influence (e.g. how the codebase is indented) I don't expect anyone to use a particular editor, I expect this project to use a particular indentation style that is not supported by only Emacs and Vim: mixing tabs and spaces. From n.oxyde@REDACTED Sun Mar 15 20:01:23 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 15 Mar 2015 20:01:23 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <90ef9959096d330c6f429258952e6689@mwinf5d54.me-wanadoo.net> References: <90ef9959096d330c6f429258952e6689@mwinf5d54.me-wanadoo.net> Message-ID: Le 15 mars 2015 ? 18:41, ?ric Pailleau a ?crit : > Hello, > > CoC is a strange name for something that looks to suck everybody. French people shouldn't do that joke, because it hurts Coq's reputation and its associated Calculus of Construction. From valentin@REDACTED Sun Mar 15 20:07:51 2015 From: valentin@REDACTED (Valentin Micic) Date: Sun, 15 Mar 2015 21:07:51 +0200 Subject: [erlang-questions] Code of Formatting In-Reply-To: <196FC375-8444-4643-A3CC-0CE3889B9159@gmail.com> References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> <517FC917-343E-4633-841A-01061188949D@pixie.co.za> <196FC375-8444-4643-A3CC-0CE3889B9159@gmail.com> Message-ID: <98B062DB-7A72-4A58-90E1-76A01F9BC3EE@pixie.co.za> Well, I do not think that you have been particularly fair in your reflection on my writing, nor critical enough regarding your original post, but let leave it as that (please). You are most welcome to think, do and expect whatever you want, for as long that is not in any way binding to anyone else. Alternatively, you better start paying wages to all this programmers that volunteer their time to contribute to your contribution. That way your expectations would be fully justified. Kind regards V/ On 15 Mar 2015, at 8:43 PM, Anthony Ramine wrote: > Le 15 mars 2015 ? 18:56, Valentin Micic a ?crit : > >> I do not understand why did my post offend you. >> I've just shared what works for me, assuming that it may work for you too. >> >> From your original post I could not deduce (and I think that no reasonable man could have) the nature of the problem, so I assumed that your "suffering" was related to the code reading. >> >> But now that you've mentioned contributing (and award winning) -- should that really entitle you to prescribe how others must write their code -- even the code that you've contributed; for you may have a reasonable expectation for a recognition (e.g. another award); however, I would disagree that this entitle you to expect others to use a particular editor/IDE (just to make it clear -- I am not trying to defend Emacs or Vim, nor am I using them). > > You assume my mail is about code reading. It's not. The OTP code with a tab width of 8 is readable. Now if you had known what are the current untold indentation rules of the code base, maybe you would have restrained yourself from telling me to just "fix" it (note your use of scare quotes as if it wasn't an actual problem) with a patch. I know that I can patch things when they are broken or need to be improved, thank you. > > I'm not entitled to prescribe how others must write their code, but I feel at least entitled to not be told to just write a patch about something that is outside of my sphere of influence (e.g. how the codebase is indented) > > I don't expect anyone to use a particular editor, I expect this project to use a particular indentation style that is not supported by only Emacs and Vim: mixing tabs and spaces. From eric.pailleau@REDACTED Sun Mar 15 20:38:30 2015 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Sun, 15 Mar 2015 20:38:30 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct Message-ID: Yes, sorry for Thierry Coquand. There is many acronyms that can fit with CoC. So many that it is a real... CoC Robin... My heart is weak and cannot resist to a joke. LOL Le 15 mars 2015 20:01, Anthony Ramine a ?crit : > > Le 15 mars 2015 ? 18:41, ?ric Pailleau a ?crit : > > > Hello, > > > > CoC is a strange name for something that looks to suck everybody. > > French people shouldn't do that joke, because it hurts Coq's reputation and its associated Calculus of Construction. From n.oxyde@REDACTED Sun Mar 15 20:39:13 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 15 Mar 2015 20:39:13 +0100 Subject: [erlang-questions] Code of Formatting In-Reply-To: <98B062DB-7A72-4A58-90E1-76A01F9BC3EE@pixie.co.za> References: <5B7C93F7-CBF9-491B-85EF-FCCC42C1B794@gmail.com> <517FC917-343E-4633-841A-01061188949D@pixie.co.za> <196FC375-8444-4643-A3CC-0CE3889B9159@gmail.com> <98B062DB-7A72-4A58-90E1-76A01F9BC3EE@pixie.co.za> Message-ID: <072CCC3D-D745-4AE8-880A-91AB7C080144@gmail.com> Le 15 mars 2015 ? 20:07, Valentin Micic a ?crit : > You are most welcome to think, do and expect whatever you want, for as long that is not in any way binding to anyone else. Alternatively, you better start paying wages to all this programmers that volunteer their time to contribute to your contribution. That way your expectations would be fully justified. How exactly can I bind anything through a post on a mailing-list? And why mention wages? Seriously, how is that related to anything we are discussing? I do not think you have been particularly fair when you wondered whether my original post lacked context for the people for whom it actually matters: current and future contributors and the OTP team. To paraphrase your first reply: assume that I had no intention for you to read my original message and even more so to reply to it because the indentation rules are out of your concern, and move on. Magnificent commendations. From me@REDACTED Sun Mar 15 19:30:35 2015 From: me@REDACTED (Leandro Ostera) Date: Sun, 15 Mar 2015 15:30:35 -0300 Subject: [erlang-questions] NFI's and running multiple VM's In-Reply-To: References: Message-ID: Thanks a million for the replies, guys. @Daniel: 1. That's what I thought. I could try this for personal use but it's clearly not the most scalable option. 2. So using ports I'd be spawning a worker that streams the audio back to the erlang process, per user that's online and listening. I'll give this a shot with pyspotify. Let's hope they allow for multiple audio streams for different sessions from the same host! 3. Unfortunately the Spotify Web API doesn't provide full playback (only 30s previews), but for the rest of the data I was going to use that. @Jesper: Indeed the library is not thread-safe. Thanks for clearing up what that meant. And it seems that they haven't updated libspotify in the past 2 years, so hopefully with the releasing of the new Web API they'll roll out a new release of the C lib. Thanks for your time guys, I'll be giving this a shot and get back. On Fri, Mar 13, 2015 at 10:43 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Thu, Mar 12, 2015 at 11:45 PM, Leandro Ostera wrote: > >> I was trying to use a quite old erlang wrapper around libspotify >> , which seems to be defining a bunch >> of NIFs, to make an audio streaming server that would keep N web-based >> clients playing the same audio at (give or take milliseconds) the same >> time. The problem is that according to one of the source files >> , >> it'd only be able to have one open Spotify session per VM, which of course >> didn't sound too exciting. >> > > The library may not be thread-safe. That is, it assumes a single thread > for access and it stores session information in global variables inside the > library itself. You may want to check if there is a newer version of the > library without these limitations. > > NIFs do support proper multithreading and local context, but the library > needs to support it as well. The term you are looking for w.r.t the context > are 'resources': > > http://www.erlang.org/doc/man/erl_nif.html#enif_resource_example > > > -- > J. > -- Leandro Ostera Github | LinkedIn | Facebook | @leostera -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sun Mar 15 21:36:55 2015 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 15 Mar 2015 21:36:55 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <5505ED67.9090006@wanadoo.fr> Le 15/03/2015 20:38, ?ric Pailleau a ?crit : > Yes, sorry for Thierry Coquand. BTW, it is a bit related to the list. Coq software is written in Ocaml (functional language ) and Mister Coquand is working at G?teborg (Sweden) ... Joe's best example : let rec factorielle = function | 0 -> 1 | n -> n * factorielle (n - 1) ;; @+ From thomasl_erlang@REDACTED Sun Mar 15 22:54:09 2015 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Sun, 15 Mar 2015 21:54:09 +0000 (UTC) Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <1059215107.1891684.1426456449935.JavaMail.yahoo@mail.yahoo.com> Hi Bruce, I'm concerned with some of the formulations _not_ associated with message formatting or line wrapping. In particular, could you expand on this section a bit?2. Hateful, hurtful, oppressive, or exclusionary remarks are not tolerated. (Cursing is strongly discouraged, but if you must curse, it may under no circumstances be used to target another user or in a hateful manner). First, what is considered "hateful", "hurtful", "oppressive" and "exclusionary" more precisely? Second, who decides on this? I consider these questions _quite important_ since you are bringing the topic up.? Best regards, Thomas On Friday, March 13, 2015 2:23 PM, Bruce Yinhe wrote: Hi everyone, To encourage a welcoming, inclusive climate for communication within the erlang.org community, the Erlang/OTP team, together with members of the community, has released a new code of conduct, available at http://www.erlang.org/download/erlang_org_code_of_conduct.txt. This code of conduct lays out a guideline of how to communicate within the erlang.org community in a way we hope is easy to read, help mutual understanding and avoid flames. The erlang.org community is by definition all communication in or around erlang.org, including but not limited to the erlang.org mailing lists or Github discussions. This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter. http://www.erlang.org/download/erlang_org_code_of_conduct.txt -- Bruce Yinhe Erlang Community ManagerIndustrial Erlang User Group community-manager@REDACTED 72 311 43 89 _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhickman386@REDACTED Sun Mar 15 23:29:21 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Sun, 15 Mar 2015 22:29:21 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5505ED67.9090006@wanadoo.fr> References: <5505ED67.9090006@wanadoo.fr> Message-ID: On a more helpful note I think that if we are to have rules then we also need a statement of purpose to keep the community on topic. For example "Erlang questions is a mailing list for the discussion of erlang programming techniques and technologies using erlang. It is also a place for people so seek help with erlang programming techniques and practices and discussion of functional programming in the context of using erlang." This is to head off things like: 1. Editor wars. Erlang programmers use emacs or vi therefore lets have a flame war 2. OS wars. Erlang runs on Windows so we can bitch about Microsoft 3. Politics. Party X's stance on H1B visas can affect programmer so lets talk about Party X 4. Language wars. Erlang is a programming language, so is X. Lets talk about X 5. Religion(?). Bet365 use erlang, gambling is immoral therefore erlang programmers are immoral 6. Products. RabbitMQ is written in erlang therefore this where I expect to get support for it Not that I have seen anything like this in this community but I have certainly seen topics raised in other communities that were very tangential to a community and shutting them down proved difficult as the posters basically held that "We are programmers, this (might) affect (some) programmers (perhaps). Therefore I will post 5,000 word rants about it". Then they get pissy when they are banned. So being upfront about the purpose of the community can at least make it clear what is going to go down badly. There are many things that concern programmers but outside of the statement of purpose this is not the place for them. Find a better place. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gguthrie@REDACTED Mon Mar 16 09:53:24 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 08:53:24 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> Message-ID: I'm glad the Erlang Community is thinking about a CoC - and I thought I would explain why. We started thinking about it in Edinburgh a couple of years ago. A lot of my friends and colleagues are Rubyists and the Ruby community always thought of itself as 'nice' and 'welcoming' but, like many other communities, built the social side of the community around drink. Then at one event a female engineer was sexually assaulted in public by her manager, after drink taken. This had a spiral of consequences that ended up with her leaving the industry - and (much less importantly) left the community in shock. At this point we started reviewing how we did things. Did we organise events with 'compulsory drinking'? Yes we did. Turns out a fair number of people (not just women) find find packs of drunk engineers unwelcoming. I have organised 3 Fringe conferences at the Turing Festival, a couple of Erlang Factory Lights, blah-blah-blah over the years - and at all of them I assumed 'be nice' was enough. Some things came out of the woodwork. There's a prominent drinks/networking meetup in London that I have attended a couple of times. A female engineering acquaintance said she wouldn't go to it be she'd been groped in public there and told the organisers and they did nothing. Other stuff emerges (not about Erlang events, but who knows): * top tips for elevator pitches, never go in an elevator with a VC * female speakers being jumped on by other speakers after he said "come up to the room and I'll give you a copy of my book" And in all of them, the point is that the assaulters were continuing on the scene, going to events, invited as speakers. At that point you start thinking "all my events were fine, weren't they?" and the answer is "I don't know". That's what a code of conduct for events is for. You want all your attendees to come forward and report problems and know that you will take them seriously and deal with it. You don't write a supervision tree for the sake of the processes that don't crash - something will go wrong and you need to have a protocol in place. But its not just codes of conduct. Started looking at other things like T-shirts. We all knock out swag t-shirts. Turns out women won't wear boxy 'unisex' t-shirts except as pyjamas - and they won't were t-shirts with slogans across the breast. As part of the Mostly Functional conference I was working on an Erlang-to-Javascript called LuvvieScript - I thought it would be cheery to have a t-shirt that had across the chest: ./rebar make_luvv Needless to say when I asked female friends about it they pointed out it was an unwearable perv magnet - walking invitation to creeps. Erk! Scrapped that plan and that t-shirt. We produce conference swag that is unwearable by female members of our community - not really welcoming. So Edinburgh is moving towards: * codes of conducts at TechMeetup and Turing * moving away from 'compulsory drinking' and making soft drinks available * fixing swag * reaching out to women speakers, other ignored groups and first time speakers We will be doing that this year at the Beam Me Up Scott.ie conference at Turing And that's a good thing. We've all seen the horrors that have been unfolding towards prominent women in tech, particularly on Twitter, the last 6 months, with death and rape threats, doxxing and swatting. I don't think people on this list were taking part in that, or that harassment happens - but I would be happier if we made a collective statement that we have processes in place and the commitment to follow them through. My elderly parents clip newspaper articles about technology and give them to me. So last week, that was the clipping I got - about how my industry was a gynocidal shit pit. That doesn't make me feel good. And if my parents know about it, there can't be a sinner on earth who doesn't share that opinion. Just my 2c Gordon On Fri, Mar 13, 2015 at 3:49 PM, Benoit Chesneau wrote: > > On Fri, Mar 13, 2015 at 4:25 PM Fred Hebert wrote: > >> On 03/13, Lo?c Hoguin wrote: >> > I see little need for a code of conduct that basically says "be nice". >> It's >> > common sense after all. >> > >> >> Then the code of conduct shall not be a problem for you. >> >> What the code does, however, is put a context around when and how >> someone can be reprimanded on the list, and for what reasons. It also >> gives a path of escalation in case of disagreement. Without one, this is >> basically left implicit to whoever is swinging the banhammer, and who >> you know or can talk to. >> >> It sets expectations and context over what is expected from members >> *and* from moderators. >> >> > > It is pointless to send a message that only warns about posting style. >> > > If you are trying to point someone to correct posting style >> > > guidelines, please do so while at least honestly attempting to answer >> > > their questions or comments. It is generally unhelpful to give only a >> > > warning related to posting style, as newcomers may feel unwelcome, >> > > only to leave. And that is exactly what we do not want. >> > >> > That's what you'll inevitably get now that you made a number of official >> > "rules" for posting style. And you'll also get the associated frame wars >> > about top and bottom posting. >> >> Then it goes against the code of conduct, please don't do that. >> Moderation can do its job, as subtle as it may be to the onlooker, or >> you can brin your problems to the moderators. Their contact info is >> listed in the code of conduct. >> >> -- >> >> Regarding top or bottom posting, I don't have strong feelings either >> way, though I do get annoyed by gmail users never filtering down the >> quoted part of posts yielding exponentially larger threads when you use >> a client that doesn't fold quotes. >> >> Regards, >> Fred. >> >> > > Why do we need a code of conduct now when we lived without it for so long? > Also since we are speaking of a community who/when was discussed that > document? Where can I find a list of the moderators? > > Also i agree discouraging people to not do top posting when most modern > client use it as a default sounds weird and not very welcoming for the new > generation... > > - benoit > > > _______________________________________________ > 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 16 10:56:24 2015 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 16 Mar 2015 09:56:24 +0000 (UTC) Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> Message-ID: <1686317266.63162.1426499784753.JavaMail.yahoo@mail.yahoo.com> Hi Gordon, do recall, however, that this is a mailing list, not a booze up in Edinburgh.? I'm concerned because most of this seems to be driven not by real needs due to eternal flame wars and off topic malformed posting on this mailing list, but by holier-than-thou posturing in Silicon Valley. The mere fact that you are mentioning "doxxing" and "swatting" gives things a very, shall we say, contemporary american feel.? What's worse is this sort of policing has already deprived or attempted to deprive several technical projects of key contributors (example 1: Ben Noordhuis in node.js). I find such a development frankly deplorable and a sign that the field is turning from technology into petty (but vicious) politics.? I would for these reasons strongly prefer not to introduce this sort of policy. I am, of course, ready and willing to be banned for my potentially insensitive, hateful, oppressive (etc) statements -- fire away, moderators. Best,Thomas On Monday, March 16, 2015 8:53 AM, Gordon Guthrie wrote: I'm glad the Erlang Community is thinking about a CoC - and I thought I would explain why. We started thinking about it in Edinburgh a couple of years ago. A lot of my friends and colleagues are Rubyists and the Ruby community always thought of itself as 'nice' and 'welcoming' but, like many other communities, built the social side of the community around drink. Then at one event a female engineer was sexually assaulted in public by her manager, after drink taken. This had a spiral of consequences that ended up with her leaving the industry - and (much less importantly) left the community in shock. At this point we started reviewing how we did things. Did we organise events with 'compulsory drinking'? Yes we did. Turns out a fair number of people (not just women) find find packs of drunk engineers unwelcoming. I have organised 3 Fringe conferences at the Turing Festival, a couple of Erlang Factory Lights, blah-blah-blah over the years - and at all of them I assumed 'be nice' was enough. Some things came out of the woodwork. There's a prominent drinks/networking meetup in London that I have attended a couple of times. A female engineering acquaintance said she wouldn't go to it be she'd been groped in public there and told the organisers and they did nothing. Other stuff emerges (not about Erlang events, but who knows):* top tips for elevator pitches, never go in an elevator with a VC* female speakers being jumped on by other speakers after he said "come up to the room and I'll give you a copy of my book" And in all of them, the point is that the assaulters were continuing on the scene, going to events, invited as speakers. At that point you start thinking "all my events were fine, weren't they?" and the answer is "I don't know". That's what a code of conduct for events is for. You want all your attendees to come forward and report problems and know that you will take them seriously and deal with it. You don't write a supervision tree for the sake of the processes that don't crash - something will go wrong and you need to have a protocol in place. But its not just codes of conduct. Started looking at other things like T-shirts. We all knock out swag t-shirts. Turns out women won't wear boxy 'unisex' t-shirts except as pyjamas - and they won't were t-shirts with slogans across the breast. As part of the Mostly Functional conference I was working on an Erlang-to-Javascript called LuvvieScript - I thought it would be cheery to have a t-shirt that had across the chest:./rebar make_luvv Needless to say when I asked female friends about it they pointed out it was an unwearable perv magnet - walking invitation to creeps. Erk! Scrapped that plan and that t-shirt. We produce conference swag that is unwearable by female members of our community - not really welcoming. So Edinburgh is moving towards:* codes of conducts at TechMeetup and Turing* moving away from 'compulsory drinking' and making soft drinks available* fixing swag* reaching out to women speakers, other ignored groups and first time speakers We will be doing that this year at the Beam Me Up Scott.ie conference at Turing And that's a good thing. We've all seen the horrors that have been unfolding towards prominent women in tech, particularly on Twitter, the last 6 months, with death and rape threats, doxxing and swatting. I don't think people on this list were taking part in that, or that harassment happens - but I would be happier if we made a collective statement that we have processes in place and the commitment to follow them through. My elderly parents clip newspaper articles about technology and give them to me. So last week, that was the clipping I got - about how my industry was a gynocidal shit pit. That doesn't make me feel good. And if my parents know about it, there can't be a sinner on earth who doesn't share that opinion. Just my 2c Gordon On Fri, Mar 13, 2015 at 3:49 PM, Benoit Chesneau wrote: On Fri, Mar 13, 2015 at 4:25 PM Fred Hebert wrote: On 03/13, Lo?c Hoguin wrote: > I see little need for a code of conduct that basically says "be nice". It's > common sense after all. > Then the code of conduct shall not be a problem for you. What the code does, however, is put a context around when and how someone can be reprimanded on the list, and for what reasons. It also gives a path of escalation in case of disagreement. Without one, this is basically left implicit to whoever is swinging the banhammer, and who you know or can talk to. It sets expectations and context over what is expected from members *and* from moderators. > > It is pointless to send a message that only warns about posting style. > > If you are trying to point someone to correct posting style > > guidelines, please do so while at least honestly attempting to answer > > their questions or comments. It is generally unhelpful to give only a > > warning related to posting style, as newcomers may feel unwelcome, > > only to leave. And that is exactly what we do not want. > > That's what you'll inevitably get now that you made a number of official > "rules" for posting style. And you'll also get the associated frame wars > about top and bottom posting. Then it goes against the code of conduct, please don't do that. Moderation can do its job, as subtle as it may be to the onlooker, or you can brin your problems to the moderators. Their contact info is listed in the code of conduct. -- Regarding top or bottom posting, I don't have strong feelings either way, though I do get annoyed by gmail users never filtering down the quoted part of posts yielding exponentially larger threads when you use a client that doesn't fold quotes. Regards, Fred. Why do we need a code of conduct now when we lived without it for so long? Also since we are speaking of a community who/when was discussed that document? Where can I find a list of the moderators? Also i agree discouraging people to not do top posting when most modern client use it as a default sounds weird ?and not very welcoming for the new generation... - benoit? _______________________________________________ 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 davidnwelton@REDACTED Mon Mar 16 10:59:05 2015 From: davidnwelton@REDACTED (David Welton) Date: Mon, 16 Mar 2015 10:59:05 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5505ED67.9090006@wanadoo.fr> Message-ID: One simple guideline I have found effective is: pretend like you're talking to someone in person. Would you say that? I certainly disagree with people in person, but do so in a respectful tone. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From vincent.dephily@REDACTED Mon Mar 16 12:37:35 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Mon, 16 Mar 2015 12:37:35 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <7928884.OY7DMUEJed@moltowork> On Saturday 14 March 2015 20:12:58 Laura M. Castro wrote: > > If I were to critique something here, it would be that the current CoC > > mixes text on social interaction[-1] (that is, how to behave with respect > > to other people) from mailing list etiquette (how to quote, how to make > > older mail readers happy[0]). > > I think this is a very good, constructive point. I agree. > > Also, from other emails in this thread, it seems to me that most of > the criticisms are directed towards the second part, so perhaps > splitting the two, as Jesper suggests, will not only benefit us as a > group if/when our activity extends to other areas/tools (i.e. the bug > tracker that he mentions), but also help us to reach consensus. Yes, spliting the document makes sense. An actual "CoC" document and a "style guide" one. May I even suggest a lightly-structured format like markdown ? I feel it would have avoided the misunderstanding that one could get banned over style rather than content. As much as I dislike bad quoting (top-posting included), it's not something that can threathen a community. Discussions about style shouldn't hinder the adoption of explicit "be nice" social interaction rules, which are IMHO important. -- Vincent de Phily From g@REDACTED Mon Mar 16 12:55:45 2015 From: g@REDACTED (Garrett Smith) Date: Mon, 16 Mar 2015 06:55:45 -0500 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: I usually bottom post. But in solidarity with Mark Allen, a long time top poster and friend, I conscientiously top post here. On Fri, Mar 13, 2015 at 9:23 AM, Bruce Yinhe wrote: > Hi everyone, > > To encourage a welcoming, inclusive climate for communication within the > erlang.org community, the Erlang/OTP team, together with members of the > community, has released a new code of conduct, available at > http://www.erlang.org/download/erlang_org_code_of_conduct.txt. This code of > conduct lays out a guideline of how to communicate within the erlang.org > community in a way we hope is easy to read, help mutual understanding and > avoid flames. The erlang.org community is by definition all communication in > or around erlang.org, including but not limited to the erlang.org mailing > lists or Github discussions. > > This code is not exhaustive or complete. It serves to distill our common > understanding of a collaborative, shared environment and goals. We expect it > to be followed in spirit as much as in the letter. Okay, I find it really hard to top post. Sorry Mark. Bruce, as what appears to be an initiative to advance the Erlang community effort, I'd keep an eye on how this happens in the future. I was surprised to see this announced as a final product. I'd have preferred to see a "call" or "request for comment" long before the initiative was undertaken. This just doesn't fit, IMO, with the spirit of open community building. A code of conduct (or style guide - as you can see by the response, it's a bit muddy) would have been a terrific rallying point for contributions across this list. I think you would have see a higher quality result and less acrimony. If the goal is to strengthen the erlang.org community, I think it's important that the community be involved openly, rather than by appointed/invited "members". I personally don't know if it's worth taking a step back here and trying this. I think having a problem definition to start is helpful. I don't know a single serious minded person who would argue that top posting is a problem. Certainly "to encourage a welcoming, inclusive climate for communication within the erlang.org community" is something we can all get behind. Ironically, I think many here would argue that the process that led to this code of conduct was very much not welcoming or inclusive. I hope that in the future, we'll see initiatives like this opened up publicly and transparently from the start. Community building is a learning process for everyone - so you could try this and see how it goes. I'm very happy to lend a hand in any way. Garrett From gguthrie@REDACTED Mon Mar 16 13:00:19 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 12:00:19 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <1686317266.63162.1426499784753.JavaMail.yahoo@mail.yahoo.com> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <1686317266.63162.1426499784753.JavaMail.yahoo@mail.yahoo.com> Message-ID: On Mon, Mar 16, 2015 at 9:56 AM, Thomas Lindgren wrote: > Hi Gordon, do recall, however, that this is a mailing list, not a booze up > in Edinburgh. > > You're correct the only thing I said about the CoC is that I support its introduction. > I'm concerned because most of this seems to be driven not by real needs > due to eternal flame wars and off topic malformed posting on this mailing > list, but by holier-than-thou posturing in Silicon Valley. The mere fact > that you are mentioning "doxxing" and "swatting" gives things a very, shall > we say, contemporary american feel. > Given that I have organised an Erlang event or 2 every year for the last 10 years in Edinburgh and many people on this list have attended or spoken at them - I think talking about what we are doing in Edinburgh for Erlang (and other) events is appropriate and on topic. I apologise if it wasn't clear that the 3 sexual assaults I mentioned (2 in the UK and 1 in the US) were introduced in that context - and not the mailing list CoC > What's worse is this sort of policing has already deprived or attempted to > deprive several technical projects of key contributors (example 1: Ben > Noordhuis in node.js). I find such a development frankly deplorable and a > sign that the field is turning from technology into petty (but vicious) > politics. > I would for these reasons strongly prefer not to introduce this sort of > policy. I am, of course, ready and willing to be banned for my potentially > insensitive, hateful, oppressive (etc) statements -- fire away, moderators. > This sort of policy for the mailing list or for events? Gordon > Best, > Thomas > > > > > On Monday, March 16, 2015 8:53 AM, Gordon Guthrie > wrote: > > > > I'm glad the Erlang Community is thinking about a CoC - and I thought I > would explain why. > > We started thinking about it in Edinburgh a couple of years ago. > > A lot of my friends and colleagues are Rubyists and the Ruby community > always thought of itself as 'nice' and 'welcoming' but, like many other > communities, built the social side of the community around drink. > > Then at one event a female engineer was sexually assaulted in public by > her manager, after drink taken. This had a spiral of consequences that > ended up with her leaving the industry - and (much less importantly) left > the community in shock. > > At this point we started reviewing how we did things. Did we organise > events with 'compulsory drinking'? Yes we did. Turns out a fair number of > people (not just women) find find packs of drunk engineers unwelcoming. > > I have organised 3 Fringe conferences at the Turing Festival, a couple of > Erlang Factory Lights, blah-blah-blah over the years - and at all of them I > assumed 'be nice' was enough. > > Some things came out of the woodwork. There's a prominent > drinks/networking meetup in London that I have attended a couple of times. > A female engineering acquaintance said she wouldn't go to it be she'd been > groped in public there and told the organisers and they did nothing. > > Other stuff emerges (not about Erlang events, but who knows): > * top tips for elevator pitches, never go in an elevator with a VC > * female speakers being jumped on by other speakers after he said "come up > to the room and I'll give you a copy of my book" > > And in all of them, the point is that the assaulters were continuing on > the scene, going to events, invited as speakers. > > At that point you start thinking "all my events were fine, weren't they?" > and the answer is "I don't know". > > That's what a code of conduct for events is for. You want all your > attendees to come forward and report problems and know that you will take > them seriously and deal with it. > > You don't write a supervision tree for the sake of the processes that > don't crash - something will go wrong and you need to have a protocol in > place. > > But its not just codes of conduct. > > Started looking at other things like T-shirts. We all knock out swag > t-shirts. Turns out women won't wear boxy 'unisex' t-shirts except as > pyjamas - and they won't were t-shirts with slogans across the breast. > > As part of the Mostly Functional conference I was working on an > Erlang-to-Javascript called LuvvieScript - I thought it would be cheery to > have a t-shirt that had across the chest: > ./rebar make_luvv > > Needless to say when I asked female friends about it they pointed out it > was an unwearable perv magnet - walking invitation to creeps. Erk! Scrapped > that plan and that t-shirt. > > We produce conference swag that is unwearable by female members of our > community - not really welcoming. > > So Edinburgh is moving towards: > * codes of conducts at TechMeetup and Turing > * moving away from 'compulsory drinking' and making soft drinks available > * fixing swag > * reaching out to women speakers, other ignored groups and first time > speakers > > We will be doing that this year at the Beam Me Up Scott.ie conference at > Turing > > And that's a good thing. > > We've all seen the horrors that have been unfolding towards prominent > women in tech, particularly on Twitter, the last 6 months, with death and > rape threats, doxxing and swatting. > > I don't think people on this list were taking part in that, or that > harassment happens - but I would be happier if we made a collective > statement that we have processes in place and the commitment to follow them > through. > > My elderly parents clip newspaper articles about technology and give them > to me. So last week, that was the clipping I got - about how my industry > was a gynocidal shit pit. That doesn't make me feel good. > > And if my parents know about it, there can't be a sinner on earth who > doesn't share that opinion. > > Just my 2c > > Gordon > > > On Fri, Mar 13, 2015 at 3:49 PM, Benoit Chesneau > wrote: > > > On Fri, Mar 13, 2015 at 4:25 PM Fred Hebert wrote: > > On 03/13, Lo?c Hoguin wrote: > > I see little need for a code of conduct that basically says "be nice". > It's > > common sense after all. > > > > Then the code of conduct shall not be a problem for you. > > What the code does, however, is put a context around when and how > someone can be reprimanded on the list, and for what reasons. It also > gives a path of escalation in case of disagreement. Without one, this is > basically left implicit to whoever is swinging the banhammer, and who > you know or can talk to. > > It sets expectations and context over what is expected from members > *and* from moderators. > > > > It is pointless to send a message that only warns about posting style. > > > If you are trying to point someone to correct posting style > > > guidelines, please do so while at least honestly attempting to answer > > > their questions or comments. It is generally unhelpful to give only a > > > warning related to posting style, as newcomers may feel unwelcome, > > > only to leave. And that is exactly what we do not want. > > > > That's what you'll inevitably get now that you made a number of official > > "rules" for posting style. And you'll also get the associated frame wars > > about top and bottom posting. > > Then it goes against the code of conduct, please don't do that. > Moderation can do its job, as subtle as it may be to the onlooker, or > you can brin your problems to the moderators. Their contact info is > listed in the code of conduct. > > -- > > Regarding top or bottom posting, I don't have strong feelings either > way, though I do get annoyed by gmail users never filtering down the > quoted part of posts yielding exponentially larger threads when you use > a client that doesn't fold quotes. > > Regards, > Fred. > > > > Why do we need a code of conduct now when we lived without it for so long? > Also since we are speaking of a community who/when was discussed that > document? Where can I find a list of the moderators? > > Also i agree discouraging people to not do top posting when most modern > client use it as a default sounds weird and not very welcoming for the new > generation... > > - benoit > > > _______________________________________________ > 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 jocke@REDACTED Mon Mar 16 13:17:22 2015 From: jocke@REDACTED (Joakim G.) Date: Mon, 16 Mar 2015 13:17:22 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <1686317266.63162.1426499784753.JavaMail.yahoo@mail.yahoo.com> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <1686317266.63162.1426499784753.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5506C9D2.9070507@tail-f.com> A CoC smells like the formalised "Common Value System" that all school children in Sweden has to accept (in writing) and discuss in "Common Value System" events (taking up to two days) each year. Klacke says that it develops their bullshit detector to a fine tuned instrument. Lets hope so. /Jocke On 2015-03-16 10:56, Thomas Lindgren wrote: > Hi Gordon, do recall, however, that this is a mailing list, not a > booze up in Edinburgh. > > I'm concerned because most of this seems to be driven not by real > needs due to eternal flame wars and off topic malformed posting on > this mailing list, but by holier-than-thou posturing in Silicon > Valley. The mere fact that you are mentioning "doxxing" and "swatting" > gives things a very, shall we say, contemporary american feel. > > What's worse is this sort of policing has already deprived or > attempted to deprive several technical projects of key contributors > (example 1: Ben Noordhuis in node.js). I find such a development > frankly deplorable and a sign that the field is turning from > technology into petty (but vicious) politics. > > I would for these reasons strongly prefer not to introduce this sort > of policy. I am, of course, ready and willing to be banned for my > potentially insensitive, hateful, oppressive (etc) statements -- fire > away, moderators. > > Best, > Thomas > > > > > On Monday, March 16, 2015 8:53 AM, Gordon Guthrie > wrote: > > > > I'm glad the Erlang Community is thinking about a CoC - and I > thought I would explain why. > > We started thinking about it in Edinburgh a couple of years ago. > > A lot of my friends and colleagues are Rubyists and the Ruby > community always thought of itself as 'nice' and 'welcoming' but, > like many other communities, built the social side of the > community around drink. > > Then at one event a female engineer was sexually assaulted in > public by her manager, after drink taken. This had a spiral of > consequences that ended up with her leaving the industry - and > (much less importantly) left the community in shock. > > At this point we started reviewing how we did things. Did we > organise events with 'compulsory drinking'? Yes we did. Turns out > a fair number of people (not just women) find find packs of drunk > engineers unwelcoming. > > I have organised 3 Fringe conferences at the Turing Festival, a > couple of Erlang Factory Lights, blah-blah-blah over the years - > and at all of them I assumed 'be nice' was enough. > > Some things came out of the woodwork. There's a prominent > drinks/networking meetup in London that I have attended a couple > of times. A female engineering acquaintance said she wouldn't go > to it be she'd been groped in public there and told the organisers > and they did nothing. > > Other stuff emerges (not about Erlang events, but who knows): > * top tips for elevator pitches, never go in an elevator with a VC > * female speakers being jumped on by other speakers after he said > "come up to the room and I'll give you a copy of my book" > > And in all of them, the point is that the assaulters were > continuing on the scene, going to events, invited as speakers. > > At that point you start thinking "all my events were fine, weren't > they?" and the answer is "I don't know". > > That's what a code of conduct for events is for. You want all your > attendees to come forward and report problems and know that you > will take them seriously and deal with it. > > You don't write a supervision tree for the sake of the processes > that don't crash - something will go wrong and you need to have a > protocol in place. > > But its not just codes of conduct. > > Started looking at other things like T-shirts. We all knock out > swag t-shirts. Turns out women won't wear boxy 'unisex' t-shirts > except as pyjamas - and they won't were t-shirts with slogans > across the breast. > > As part of the Mostly Functional conference I was working on an > Erlang-to-Javascript called LuvvieScript - I thought it would be > cheery to have a t-shirt that had across the chest: > ./rebar make_luvv > > Needless to say when I asked female friends about it they pointed > out it was an unwearable perv magnet - walking invitation to > creeps. Erk! Scrapped that plan and that t-shirt. > > We produce conference swag that is unwearable by female members of > our community - not really welcoming. > > So Edinburgh is moving towards: > * codes of conducts at TechMeetup and Turing > * moving away from 'compulsory drinking' and making soft drinks > available > * fixing swag > * reaching out to women speakers, other ignored groups and first > time speakers > > We will be doing that this year at the Beam Me Up Scott.ie > conference at Turing > > And that's a good thing. > > We've all seen the horrors that have been unfolding towards > prominent women in tech, particularly on Twitter, the last 6 > months, with death and rape threats, doxxing and swatting. > > I don't think people on this list were taking part in that, or > that harassment happens - but I would be happier if we made a > collective statement that we have processes in place and the > commitment to follow them through. > > My elderly parents clip newspaper articles about technology and > give them to me. So last week, that was the clipping I got - about > how my industry was a gynocidal shit pit. That doesn't make me > feel good. > > And if my parents know about it, there can't be a sinner on earth > who doesn't share that opinion. > > Just my 2c > > Gordon > > > On Fri, Mar 13, 2015 at 3:49 PM, Benoit Chesneau > > wrote: > > > On Fri, Mar 13, 2015 at 4:25 PM Fred Hebert > wrote: > > On 03/13, Lo?c Hoguin wrote: > > I see little need for a code of conduct that basically > says "be nice". It's > > common sense after all. > > > > Then the code of conduct shall not be a problem for you. > > What the code does, however, is put a context around when > and how > someone can be reprimanded on the list, and for what > reasons. It also > gives a path of escalation in case of disagreement. > Without one, this is > basically left implicit to whoever is swinging the > banhammer, and who > you know or can talk to. > > It sets expectations and context over what is expected > from members > *and* from moderators. > > > > It is pointless to send a message that only warns > about posting style. > > > If you are trying to point someone to correct posting > style > > > guidelines, please do so while at least honestly > attempting to answer > > > their questions or comments. It is generally unhelpful > to give only a > > > warning related to posting style, as newcomers may > feel unwelcome, > > > only to leave. And that is exactly what we do not want. > > > > That's what you'll inevitably get now that you made a > number of official > > "rules" for posting style. And you'll also get the > associated frame wars > > about top and bottom posting. > > Then it goes against the code of conduct, please don't do > that. > Moderation can do its job, as subtle as it may be to the > onlooker, or > you can brin your problems to the moderators. Their > contact info is > listed in the code of conduct. > > -- > > Regarding top or bottom posting, I don't have strong > feelings either > way, though I do get annoyed by gmail users never > filtering down the > quoted part of posts yielding exponentially larger threads > when you use > a client that doesn't fold quotes. > > Regards, > Fred. > > > > Why do we need a code of conduct now when we lived without it > for so long? Also since we are speaking of a community > who/when was discussed that document? Where can I find a list > of the moderators? > > Also i agree discouraging people to not do top posting when > most modern client use it as a default sounds weird and not > very welcoming for the new generation... > > - benoit > > _______________________________________________ > 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 n.oxyde@REDACTED Mon Mar 16 14:09:21 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Mar 2015 14:09:21 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> Message-ID: <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> Le 16 mars 2015 ? 09:53, Gordon Guthrie a ?crit : > Started looking at other things like T-shirts. We all knock out swag t-shirts. Turns out women won't wear boxy 'unisex' t-shirts except as pyjamas - and they won't were t-shirts with slogans across the breast. > > As part of the Mostly Functional conference I was working on an Erlang-to-Javascript called LuvvieScript - I thought it would be cheery to have a t-shirt that had across the chest: > ./rebar make_luvv > > Needless to say when I asked female friends about it they pointed out it was an unwearable perv magnet - walking invitation to creeps. Erk! Scrapped that plan and that t-shirt. > > We produce conference swag that is unwearable by female members of our community - not really welcoming. In which puritan world do you live in? I don't want to work in that world. I suppose any anecdotes I could present to oppose that one will be dismissed under the pretext that I don't understand that problem. From gguthrie@REDACTED Mon Mar 16 14:24:17 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 13:24:17 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> Message-ID: Seriously, women saying "I don't want to wear a T-shirt which gives men an excuse to stare at my tits" isn't puritanism. Its not that hard. G On Mon, Mar 16, 2015 at 1:09 PM, Anthony Ramine wrote: > Le 16 mars 2015 ? 09:53, Gordon Guthrie a ?crit : > > > Started looking at other things like T-shirts. We all knock out swag > t-shirts. Turns out women won't wear boxy 'unisex' t-shirts except as > pyjamas - and they won't were t-shirts with slogans across the breast. > > > > As part of the Mostly Functional conference I was working on an > Erlang-to-Javascript called LuvvieScript - I thought it would be cheery to > have a t-shirt that had across the chest: > > ./rebar make_luvv > > > > Needless to say when I asked female friends about it they pointed out it > was an unwearable perv magnet - walking invitation to creeps. Erk! Scrapped > that plan and that t-shirt. > > > > We produce conference swag that is unwearable by female members of our > community - not really welcoming. > > In which puritan world do you live in? I don't want to work in that world. > I suppose any anecdotes I could present to oppose that one will be > dismissed under the pretext that I don't understand that problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Mar 16 14:28:28 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Mar 2015 14:28:28 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> Message-ID: <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> Le 16 mars 2015 ? 14:24, Gordon Guthrie a ?crit : > Seriously, women saying "I don't want to wear a T-shirt which gives men an excuse to stare at my tits" isn't puritanism. > > Its not that hard. And when do we stop catering to the fragile feelings of everyone? Why not make that t-shirt for whoever wanted to wear it? How do you know no women would have wore it? From gguthrie@REDACTED Mon Mar 16 14:34:59 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 13:34:59 +0000 Subject: [erlang-questions] Fwd: Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> Message-ID: I asked them. On Mon, Mar 16, 2015 at 1:28 PM, Anthony Ramine wrote: > Le 16 mars 2015 ? 14:24, Gordon Guthrie a ?crit : > > > Seriously, women saying "I don't want to wear a T-shirt which gives men > an excuse to stare at my tits" isn't puritanism. > > > > Its not that hard. > > And when do we stop catering to the fragile feelings of everyone? Why not > make that t-shirt for whoever wanted to wear it? How do you know no women > would have wore it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Mar 16 14:46:44 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Mar 2015 14:46:44 +0100 Subject: [erlang-questions] Fwd: Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> Message-ID: <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Le 16 mars 2015 ? 14:34, Gordon Guthrie a ?crit : > I asked them. What about making sure no pervert look at them wrongly instead of scrapping the t-shirt? That was the best part of LuvvieScript after all. I don't want to live in a world where we must remove all things that might make people feel awkward or harassed by third parties instead of actually fixing the mentalities of these third parties. From gguthrie@REDACTED Mon Mar 16 14:49:26 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 13:49:26 +0000 Subject: [erlang-questions] Fwd: Announcing Erlang.org Code of Conduct In-Reply-To: <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Message-ID: Very droll, but not very practical. On Mon, Mar 16, 2015 at 1:46 PM, Anthony Ramine wrote: > Le 16 mars 2015 ? 14:34, Gordon Guthrie a ?crit : > > > I asked them. > > What about making sure no pervert look at them wrongly instead of > scrapping the t-shirt? That was the best part of LuvvieScript after all. I > don't want to live in a world where we must remove all things that might > make people feel awkward or harassed by third parties instead of actually > fixing the mentalities of these third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Mar 16 14:52:49 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Mar 2015 14:52:49 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Message-ID: Le 16 mars 2015 ? 14:49, Gordon Guthrie a ?crit : > Very droll, but not very practical. So we should just forfeit, and consider that there are sexist people and harassers among your conferences that you just can't get rid of? So sad. From gguthrie@REDACTED Mon Mar 16 15:00:06 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 14:00:06 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Message-ID: Sorry, I don't understand. I have listed the steps we are taking. What would you do differently? On Mon, Mar 16, 2015 at 1:52 PM, Anthony Ramine wrote: > Le 16 mars 2015 ? 14:49, Gordon Guthrie a ?crit : > > > Very droll, but not very practical. > > So we should just forfeit, and consider that there are sexist people and > harassers among your conferences that you just can't get rid of? So sad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Mar 16 15:01:39 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Mar 2015 15:01:39 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Message-ID: Le 16 mars 2015 ? 15:00, Gordon Guthrie a ?crit : > Sorry, I don't understand. > > I have listed the steps we are taking. > > What would you do differently? I wouldn't self-censor my amusing t-shirts because some people are harassers, for starters. From gguthrie@REDACTED Mon Mar 16 15:02:29 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 14:02:29 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Message-ID: Yes, you've said that. But you might want to say something you would do. On Mon, Mar 16, 2015 at 2:01 PM, Anthony Ramine wrote: > Le 16 mars 2015 ? 15:00, Gordon Guthrie a ?crit : > > > Sorry, I don't understand. > > > > I have listed the steps we are taking. > > > > What would you do differently? > > I wouldn't self-censor my amusing t-shirts because some people are > harassers, for starters. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Mar 16 15:04:46 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Mar 2015 15:04:46 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Message-ID: <979B07AB-B42F-4BF0-8828-104EF72D9597@gmail.com> Le 16 mars 2015 ? 15:02, Gordon Guthrie a ?crit : > Yes, you've said that. > > But you might want to say something you would do. The only logical thing to do: dispose of harassers when you discover they are. Not try to hide their presence by removing elements that might make the worst part of themselves appear. From gguthrie@REDACTED Mon Mar 16 15:09:36 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Mon, 16 Mar 2015 14:09:36 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <979B07AB-B42F-4BF0-8828-104EF72D9597@gmail.com> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> <979B07AB-B42F-4BF0-8828-104EF72D9597@gmail.com> Message-ID: On Mon, Mar 16, 2015 at 2:04 PM, Anthony Ramine wrote: > Le 16 mars 2015 ? 15:02, Gordon Guthrie a ?crit : > > > Yes, you've said that. > > > > But you might want to say something you would do. > > The only logical thing to do: dispose of harassers when you discover they > are. Not try to hide their presence by removing elements that might make > the worst part of themselves appear. > I propose to do that by making it clear that if these events occur: * the person being harassed will be believed * action will be taken * the harasser will be removed I intend to do this by writing it down and making it known in advance of any event I organise. I call this 'a code of conduct'. Also, having tested my promotional material (t-shirts, etc) with the target audience I will continue to try and find ones that have the widest possible appeal. Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Mar 16 16:24:11 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 16 Mar 2015 16:24:11 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> <979B07AB-B42F-4BF0-8828-104EF72D9597@gmail.com> Message-ID: On Mon, Mar 16, 2015 at 3:09 PM, Gordon Guthrie wrote: > I propose to do that by making it clear that if these events occur: > * the person being harassed will be believed > * action will be taken > * the harasser will be removed > This works perfectly until you hit the case where the person being "harassed" has a personality disorder in Cluster B. While most people are reasonable beings, who should be believed on their words, there are a few exceptions. The risk is luckily pretty low, but grows steadily with conference size. Be careful with blindly abolishing the concept of due process, as action might be taken against the harassed and not the harasser. In this discussion, we are fortunate in the sense that it isn't a conference, which are much harder to handle and requires more diligence than what is needed for a mailing list. The addition of somewhat confined physical space in itself poses an area which needs special care and handling. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil@REDACTED Mon Mar 16 16:44:17 2015 From: ali.sabil@REDACTED (Ali Sabil) Date: Mon, 16 Mar 2015 16:44:17 +0100 Subject: [erlang-questions] Why does Dialyzer crash on this map? In-Reply-To: References: <54749C90.6000602@llaisdy.com> <5474BA4C.4030706@llaisdy.com> <547716F8.7010208@llaisdy.com> <4B9AEB77-A709-4D97-8EF2-8FE1AF5A4071@llaisdy.com> Message-ID: On Fri, Mar 13, 2015 at 11:35 AM, Ali Sabil wrote: > Tried with the OTP master, and the issue is still there. > > Does the following patch make any sense? diff --git a/lib/dialyzer/src/dialyzer_dataflow.erl b/lib/dialyzer/src/dialyzer_dataflow.erl index 03005e6..3cdbf35 100644 --- a/lib/dialyzer/src/dialyzer_dataflow.erl +++ b/lib/dialyzer/src/dialyzer_dataflow.erl @@ -3477,6 +3477,7 @@ find_terminals(Tree) -> 'let' -> find_terminals(cerl:let_body(Tree)); letrec -> find_terminals(cerl:letrec_body(Tree)); literal -> {false, true}; + map -> {false, true}; primop -> {false, false}; %% match_fail, etc. are not explicit exits. 'receive' -> Timeout = cerl:receive_timeout(Tree), -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Mon Mar 16 23:52:29 2015 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 16 Mar 2015 23:52:29 +0100 Subject: [erlang-questions] Fwd: Announcing Erlang.org Code of Conduct In-Reply-To: <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <99F2315E-D2C3-49F9-B79B-CE1528694DA0@gmail.com> <40FEE3E0-9670-4418-8A9F-11063D897BB6@gmail.com> <311C155C-6FE0-4B3B-80CA-0BA4C438966D@gmail.com> Message-ID: <55075EAD.3040406@wanadoo.fr> Le 16/03/2015 14:46, Anthony Ramine a ?crit : > Le 16 mars 2015 ? 14:34, Gordon Guthrie a ?crit : > >> I asked them. > > What about making sure no pervert look at them wrongly instead of scrapping the t-shirt? That was the best part of LuvvieScript after all. I don't want to live in a world where we must remove all things that might make people feel awkward or harassed by third parties instead of actually fixing the mentalities of these third parties. > _______________________________________________ Agree with you Anthony , but we are living in a country where relationship between men and women are probably less gladiatorial . A subtle blend of courtesy, courtship and mistrust, where a man and a woman can be alone in a room with door closed. Women have breasts ? so what ? Do they have to remove their breast in order to save the T-shirt industry ? No, for sure. Women we meet in the street everyday are feminist AND disappointed if men do not have a short stare to them . Complicated, as life is. it is only a question of respect. binge drinking is probably a bad habit that comes here too, the main problem MHO. Harasser ? there are laws against them. The Code of Conduct have to to mention that harassers will be criminally prosecuted by event organizers, even if the harassed woman won't prosecute. The "Code of Conduct" cannot replace local laws, but only regulate what is not forbidden. CoC for a mailing list is more complicated because there is no real law on Internet. "Be nice" is probably the most reasonable statement. "Be lenient" is the second, in particular to my pathetic jokes... :) Regards From ok@REDACTED Tue Mar 17 00:27:09 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 17 Mar 2015 12:27:09 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> On 14/03/2015, at 3:23 am, Bruce Yinhe wrote: > Hi everyone, > > To encourage a welcoming, inclusive climate for communication within the erlang.org community, the Erlang/OTP team, together with members of the community, has released a new code of conduct, Did we really have a big problem? *Which* members of "the community" and how were they selected? Only three names appear on the code, which hardly exhausts the Erlang/OTP team, let alone being *representative* of the community. I note that the code says "We encourage you to limit your messages to plain text" but what I'm seeing is an HTML message with very long lines. Not to lay burdens on other's shoulders that you aren't willing to bear yourselves, eh? > > This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter. "Our" common understanding? What makes you think you speak for me? (English doesn't have enough pronouns. Using Tok Pisin, I _think_ you mean "mipela" (2nd person plural exclusive, the writers of the code and nobody else) but it _looks_ like "yumipela" (you-and-me, 2nd person plural inclusive. The lack of the inclusive/exclusive distinction in English has bugged me since I was five.) Content policy. 1. Be nice to each other. [You could stop there.] 2. ... [Redundant, given 1. It says "curse" where I think "swear" is meant.] 3. No SPAM. [Assumes that the reader understands clearly what SPAM is. The term is fairly recent and informal. We have people who are struggling with English as well as Erlang, and it is not clear to me that they may be assumed to know what the term means. Give a definition or a link to one.] 4. "The are" [Should probably be "There are".] Style policy. 4. [The people who "top post" probably don't even know the term "to top post" and may well not know that there is any other way to do it. Given some of the horrible MUAs out there, it may be far from obvious how to do it right. Maybe we need to find or build up a list of "how to be nice in MUA XYZZY" articles?] 5. "Try to break your lines" [I would very much like to see people do this. Once again, however, we have a technical term "to break a line" that the people who misbehave probably do not know. Why not simply say "Keep your lines short. Use the RETURN key to end each line; do not assume that your readers will see your text wrapped the way you see it." It would be gracious to include a link to the venerable Emily Postnews? http://www.templetons.com/brad/emily.html From raould@REDACTED Tue Mar 17 00:31:54 2015 From: raould@REDACTED (Raoul Duke) Date: Mon, 16 Mar 2015 16:31:54 -0700 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> Message-ID: why can't the whole thing be replace with "be nice when you send; use a REAL mail reader when you read"?!?!?!?! While I have always kind of hated HTML email, and been a long-time die-hard Emacs user for doing my email & usenet, I think after all if you do not have a mail reader than can convert HTML into something that looks good to you, then you frankly do not deserve to call yourself a hacker/developer/whatever. And if you are not a hacker/developer/whatever, then what the hell are you doing using Emacs to read email instead of a GUI??!?!?!!! From raould@REDACTED Tue Mar 17 01:25:05 2015 From: raould@REDACTED (Raoul Duke) Date: Mon, 16 Mar 2015 17:25:05 -0700 Subject: [erlang-questions] whatever happened to... Message-ID: bthreads? http://www.wisdom.weizmann.ac.il/mathusers/amarron/bp-sigerl2010.pdf :-) From e@REDACTED Tue Mar 17 04:10:53 2015 From: e@REDACTED (e@REDACTED) Date: Tue, 17 Mar 2015 04:10:53 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5502F86D.1090705@ninenines.eu> References: <5502F86D.1090705@ninenines.eu> Message-ID: <55079B3D.1010207@bestmx.net> On 03/13/2015 03:47 PM, Lo?c Hoguin wrote: > I see little need for a code of conduct that basically says "be nice". > It's common sense after all. noted. if a rule follows the common practice it has little sense > > 4. Top posting is discouraged. > In a world where the most used clients use top posting by default, this > rule makes little sense. noted. if a rule contradicts the common practice it has little sense may i ask, if you are simply against all rules generally? regarding this 4th rule, i love it! this rule alone makes the code necessary!!! and even more so in the world of utterly bad practices, such as top posting. From e@REDACTED Tue Mar 17 04:26:39 2015 From: e@REDACTED (e@REDACTED) Date: Tue, 17 Mar 2015 04:26:39 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <55030825.7080404@ninenines.eu> References: <5502F86D.1090705@ninenines.eu> <20150313152541.GP63925@ferdair.local> <55030825.7080404@ninenines.eu> Message-ID: <55079EEF.2020103@bestmx.net> On 03/13/2015 04:54 PM, Lo?c Hoguin wrote: > On 03/13/2015 04:25 PM, Fred Hebert wrote: >> On 03/13, Lo?c Hoguin wrote: >>> I see little need for a code of conduct that basically says "be >>> nice". It's >>> common sense after all. >>> >> >> Then the code of conduct shall not be a problem for you. >> >> What the code does, however, is put a context around when and how >> someone can be reprimanded on the list, and for what reasons. It also >> gives a path of escalation in case of disagreement. Without one, this is >> basically left implicit to whoever is swinging the banhammer, and who >> you know or can talk to. >> >> It sets expectations and context over what is expected from members >> *and* from moderators. > > I am not so concerned about my behavior. Read it or not, most people > will post fine. I am more concerned about the side effects of rules. > > When you write down rules, you always end up with some unrelated people > trying to enforce these rules, despite it not being their job. This can > create unnecessary conflicts. A number of these people will also try to > enforce the word of the rules rather than their spirit. it is a known issue. and, yes, it is very serious issue. usually it is stated in a top article of a CoC: "unsolicited moderation is punishable with life long ban without prior notice" optionally all "style-guide" postings are also forbidden and mildly punished. also it is very important to maintain a separate communication channel for keeping the conference completely free from all moderatorial messages. > There also doesn't seem to be in the CoC an explanation of the process > to either defend yourself (as you point out, not everyone is native > English speaker, so misunderstanding happen and they do quite > regularly), nor is there an explanation for how to redeem yourself. > > This is a problem to me because every few months I manage to offend > someone without meaning it. A few weeks ago I got attacked when all I > tried to do was make a compliment, to give you an example. > > And as Benoit points out, it's a concern that we don't know who the > moderators are and how they are selected. I have seen way too often > moderators ban people on a whim due to personal issues rather than rules > being broken. > From erlang-questions@REDACTED Tue Mar 17 09:47:42 2015 From: erlang-questions@REDACTED (Roger Price) Date: Tue, 17 Mar 2015 09:47:42 +0100 (CET) Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> Message-ID: On Tue, 17 Mar 2015, Richard A. O'Keefe wrote: > It would be gracious to include a link to the venerable Emily Postnews? > http://www.templetons.com/brad/emily.html And also to Eric Raymond on "How To Ask Questions The Smart Way" http://www.catb.org/esr/faqs/smart-questions.html Roger From erlang@REDACTED Tue Mar 17 14:02:16 2015 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 17 Mar 2015 14:02:16 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> Message-ID: My Mother, was brought up by her Grandmother, this was because her Mother died of the Spanish Flu when she was little. My Gradmother swore by Lady Hartley's "Ladies book of Etiquette and Manual of Politness" (1875) and my Mother often used to quote from it at length when I was a child. Lady Hartley's rules occupied 356 pages - and there is no way they could be summarized as "be nice." Thanks to the amazing advances in technology the entire text of Lady Hartleys' text can be perused on-line at https://archive.org/details/ladiesbookofetiq00hartrich She didn't actually mention email in her book, but there is a chapter on letter writing (which is the nearest we'll get) Chapter XV starts: LETTER WRITING THERE is no branch of education called so universally into requisition as the art of letter writing ; no station, high or low, where the necessity for correspondence is not felt ; no person, young or old, who does not, at some time, write, cause to be written, and receive letters. From the President in his official capacity, with the busy pens of secretaries constantly employed in this branch of service, to the Irish laborer who, unable to guide a pen, writes, also by proxy, to his kinsfolks across the wide ocean ; all, at some time, feel the desire to transmit some message, word of love, business, or sometimes enmity, by letter. and gushes on for 26 pages - great stuff - well worth including as an appendix to our rules. --- As for being nice ... Do I really have to be nice? - some of the best stuff I've read wasn't nice - Caitlin Moran's books would not have made it to the best seller lists and reduced me to tears of laughter if she'd been nice. Cut out the non-nice bits and swear words and there would be very little left. Miss Jones in my little school days said "never ever *ever* use the word nice." it shows a lack of imagination. Don't say it's "nice weather" say it's "pleasant weather" or some. Don't say "that's nice" say "that's interesting" As for not swearing - the odd frog, badger or reference to a furry animal in the text can hardly be wrong. It would be helpful to have a list of forbidden words here ... ---- My Father had views on etiquette: His only advince on the matter was "always tip your hat to a lady" Sorry about the top post. /Joe On Tue, Mar 17, 2015 at 9:47 AM, Roger Price wrote: > On Tue, 17 Mar 2015, Richard A. O'Keefe wrote: > >> It would be gracious to include a link to the venerable Emily Postnews? >> http://www.templetons.com/brad/emily.html > > > And also to Eric Raymond on "How To Ask Questions The Smart Way" > http://www.catb.org/esr/faqs/smart-questions.html > > Roger > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Tue Mar 17 14:53:12 2015 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 17 Mar 2015 14:53:12 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way Message-ID: How do I include another application in my application? I've written a program that I want to distibute. I'll make it available on github. The problem is that my program uses cowboy and a few other things (which are also on github) I'd like my program to work "out of the box" - just type Make and off you go. I'd also like my to work for a long time so if rebar and cowboy change in the future I'd like my program to still build correctly. Now what I could do is: use rebar and a rebar.config file that point to cowboy etc. My rebar-config is like this {deps, [ ... {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}} ]}. The problem with this is that 1) my version of rebar might not be the same as on the target machine where the makefile is run 2) The cowboy reference is to "the latest version" and not an immutable version that I know works So How should I fix this? Is the answer: a) Include rebar in my distribution (I don't really like this, since I'd just like to have my code in my project archive) b) Point to a absolute version of cowboy - but how do I do this? Or c) Include all the source code of cowboy etc in my release I also don't want mutiple versions of rebar and libraries in different directories, branches, views or whatever you call them. What's the best thing to do here? Cheers /Joe From erlang@REDACTED Tue Mar 17 14:55:00 2015 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 17 Mar 2015 14:55:00 +0100 Subject: [erlang-questions] A question of style Message-ID: A Question of Style The other day I was writing a program that called some library code that I had written. The library had a routine that could parse a string: -module(my_lib). -export([parse_string/1]). ... In the code I was writing I had a binary B containing a string that I wanted parsing. I was faced with two alternatives: 1) call my_lib:parse_string(binary_to_list(B)) Or 2) Add an addition interface routine to my_lib and call this from the module I was writing, so my_lib now becomes: -module(my_lib). -export([parse_string/1, parse_binary/1]). parse_binary(B) -> parse_string(binary_to_lost(B)) and the calling code is my_lib:parse_binary(B) Now for many years I have almost automatically chosen option 2) - with the reasoning "make the library easy to use with lot's of interface functions" But suddenly an alternative thought struck me: "adding lots of convenience interface functions to the library code makes the library code difficult to understand" - it difficult to see at a glance what the "essential functionality" of the library and to distinguish the essential functionality from the convenience and non-essential functions. So is this true: easy to use the library == not easy to understand the library code Looking through the Erlang library code, we see the nightmarish results of the philosophy of "making the library code easy to call" - there are loads of convenience functions cluttering up the code to the extent that it becomes difficult to see what is going on. (this seems paradoxical - libraries/frameworks that are "easy" to use tend to be large - and horribly difficult to understand when they don't do exactly what you want, but understanding how they work seems essential in using them correctly) Example: File names; are they strings, binaries, atoms or deep-lists? I guess you'll find all of these used in an inconsistent manner. This multiple representation of filenames seems to be an example of chronic "can't make you mind up ism", is it a bird or a plane? I dunno, it's both. With directory names things get even worse - it's all the complexity of a filename with the added problem of wondering whether or not the directory name ended with a "/" or not. Half the code in the system does, the other half doesn't :-) I got to thinking about libraries in general, it had been my misfortune to program some C using the mac audio API - here there are so many functions that it's virtually impossible to distinguish the essential functions (from which all other functions can be constructed) from the convenience functions that merely call the essential functions, omitting the odd argument or so and performing the odd data-type conversion. After a bit of thought I decided to re-write parts of my library code. I decide that internally I'd only use lists and I'd remove all the convenience functions. The result was library code that was far shorter and easier to understand. I made a design decision to minimize the use of binaries for string processing and only use lists of integers (on input I use binaries and convert them to lists) on output I convert the lists to binaries (but no messing in the middle of my code). Previously I have a lot of code with binary_to_list and list_to_binary all over the place - all my problems with utf8/latin1 etc. almost vanished. The data comes in as a UTF8 binary (or something) but then gets immediately converted to a list of integer character Unicode code points and stays that way as long as possible. The more I think about it the more I come to the conclusion that we should not be writing polymorphic interfaces to libraries and making them easy to use. Instead we should be writing minimal libraries containing only essential features. We should make our minds up about things like filenames, directory names etc. representations and we should enforce them uniformly accross all libraries. (My choice would be that filenames are always represented by flat lists of Unicode integers, directory names always have a trailing "/") etc. Paradoxically the goal of making a particular library easy to use by offering multiple polymorphic entry points not only makes it far more difficult to understand, but difficult to compose the code in different modules. Polymorphic data types muck up the type signatures since the types of the polymorphic arguments tend to escape the module and propagate silly types all over the place. Note: a similar argument can be made for code that provides default arguments to a generic function. Suppose we have an essential function with seven arguments, should we provide half a dozen helper functions that provide default arguments the the big function in different ways? So am I right? - should we junk all the convenience functions in a module and stick to essential functionality offering only one way to do something? I'll do this for a while and see what happens. Cheers /Joe From mfidelman@REDACTED Tue Mar 17 14:52:57 2015 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 17 Mar 2015 09:52:57 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> Message-ID: <550831B9.2000505@meetinghouse.net> Joe Armstrong wrote: > My Mother, was brought up by her Grandmother, this was because her > Mother died of the Spanish Flu when she was little. > > My Gradmother swore by Lady Hartley's "Ladies book of Etiquette and > Manual of Politness" (1875) and my Mother often used to quote from it > at length when I was a child. > > Lady Hartley's rules occupied 356 pages - and there is no way they > could be summarized as "be nice." > > Then again, as Rabbi Hillel famously said ?That which is hateful to you, do not unto another: This is the whole Torah. The rest is commentary" (of course the quote concludes with ? [and now] go study.?) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From essen@REDACTED Tue Mar 17 15:07:44 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 17 Mar 2015 15:07:44 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: Message-ID: <55083530.2070108@ninenines.eu> On 03/17/2015 02:53 PM, Joe Armstrong wrote: > How do I include another application in my application? > > I've written a program that I want to distibute. > I'll make it available on github. > > The problem is that my program uses cowboy and a few other > things (which are also on github) > > I'd like my program to work "out of the box" - just type Make and off > you go. > > I'd also like my to work for a long time so if rebar and > cowboy change in the future I'd like my program to still build > correctly. > > Now what I could do is: > > use rebar and a rebar.config file that point to cowboy etc. > > My rebar-config is like this > > {deps, [ > ... > {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}} > ]}. > > The problem with this is that > > 1) my version of rebar might not be the same as on the target machine > where the makefile is run This is a problem erlang.mk solves. You include erlang.mk in your project therefore everyone has the same when they compile it. You still are at the whim of Make having an incompatible change that breaks something, but you also have that issue with rebar when a newer Erlang version breaks something in it. The chances of either happening are very slim though. > 2) The cowboy reference is to "the latest version" and not > an immutable version that I know works > > So How should I fix this? Is the answer: > > a) Include rebar in my distribution > (I don't really like this, since I'd just like to have my code in > my project archive) That's what I would advise you to do, though. Do note however that if your project is to be used as a dependency then it won't be your rebar that will be used but the user's (or the top-level project's) rebar. This is another issue erlang.mk solves as the dependency's Makefile is always used and not the top-level erlang.mk. The dependency can run a different erlang.mk or just a plain Makefile, or even a Makefile that calls the bundled rebar, it doesn't matter as long as there is a Makefile. > b) Point to a absolute version of cowboy - but how do I do this? Simply put the tag or commit number instead of "master" in rebar.config, for example "1.0.1". Make sure to do this with all your dependencies, and check that the dependencies themselves do it. I believe rebar3 has a way to lock dependencies into a specific commit for the projects that depend on another's "master". > Or c) > Include all the source code of cowboy etc in my release This also works but will prove to be more time consuming when you need to update dependencies. However if you intend to just release the project and make little maintenance over it afterward (for example if it's a proof of concept or a prototype) then this might just be the way to go. -- Lo?c Hoguin http://ninenines.eu From boris.muehmer@REDACTED Tue Mar 17 15:08:13 2015 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Tue, 17 Mar 2015 15:08:13 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: Message-ID: Hi Joe, about Your "how should I fix this" section there may be a way, when You already use git are "submodules". With such a submodule You can include a git repository and it will be fixed at a given commit. But there is another problem with other's (git-) repositories: what will happen when the project dies, or is moved to another "namespace". Of course You can use a fork and use this as a base for a submodule, but with this approach You may have to keep Your fork in sync with the original one. [IMHO] On the other hand the "git submodule usage" is somewhat cumbersome... Regards, Boris 2015-03-17 14:53 GMT+01:00 Joe Armstrong : > How do I include another application in my application? > > I've written a program that I want to distibute. > I'll make it available on github. > > The problem is that my program uses cowboy and a few other > things (which are also on github) > > I'd like my program to work "out of the box" - just type Make and off > you go. > > I'd also like my to work for a long time so if rebar and > cowboy change in the future I'd like my program to still build > correctly. > > Now what I could do is: > > use rebar and a rebar.config file that point to cowboy etc. > > My rebar-config is like this > > {deps, [ > ... > {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}} > ]}. > > The problem with this is that > > 1) my version of rebar might not be the same as on the target machine > where the makefile is run > 2) The cowboy reference is to "the latest version" and not > an immutable version that I know works > > So How should I fix this? Is the answer: > > a) Include rebar in my distribution > (I don't really like this, since I'd just like to have my code in > my project archive) > b) Point to a absolute version of cowboy - but how do I do this? > > Or c) > Include all the source code of cowboy etc in my release > > I also don't want mutiple versions of rebar and libraries in different > directories, branches, views or whatever you call them. > > What's the best thing to do here? > > Cheers > > /Joe > _______________________________________________ > 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 17 15:26:52 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 17 Mar 2015 10:26:52 -0400 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: <55083530.2070108@ninenines.eu> References: <55083530.2070108@ninenines.eu> Message-ID: <20150317142651.GB11827@ferdair.local> On 03/17, Lo?c Hoguin wrote: > I believe rebar3 has a way to lock dependencies into a specific commit for > the projects that depend on another's "master". Yes. It's done automatically when compiling, building releases, or any other command that depends on compiled modules being there (an explicit `rebar3 lock' command can be run too). --- Another answer that Joe might want is the possibility of using releases. Whether it's with systools, reltool, relx (possibly via erlang.mk or rebar3), releases allow you to ship an Erlang program with its minimal version of the Erlang VM, with the code pre-compiled. This at least removes the requirement that the user has Erlang or make installed, and makes it so Joe (or the release creator) used a similar runtime system to compile the application, or took specific steps to cross-compile. Releases also have the option to ship without stdlibs or the ERTS in case you want them to run on a target system with an existing copy of Erlang in there. If the code uses no NIFs, such portable releases are really the best way to go about distributing Erlang code. The big constraint is that you must write OTP applications for these to work, which I know Joe sometimes likes not to do (a supervisor bridge may help such cases: http://www.erlang.org/doc/man/supervisor_bridge.html Regards, Fred. From g@REDACTED Tue Mar 17 15:58:47 2015 From: g@REDACTED (Garrett Smith) Date: Tue, 17 Mar 2015 09:58:47 -0500 Subject: [erlang-questions] A question of style In-Reply-To: References: Message-ID: I'm now starting my replies with a top post. On Tue, Mar 17, 2015 at 8:55 AM, Joe Armstrong wrote: > > A Question of Style -snip- > After a bit of thought I decided to re-write parts of my library > code. I decide that internally I'd only use lists and I'd remove all > the convenience functions. > > The result was library code that was far shorter and easier to > understand. I made a design decision to minimize the use of binaries > for string processing and only use lists of integers (on input I use > binaries and convert them to lists) on output I convert the lists to > binaries (but no messing in the middle of my code). Previously I have > a lot of code with binary_to_list and list_to_binary all over the > place - all my problems with utf8/latin1 etc. almost vanished. The > data comes in as a UTF8 binary (or something) but then gets > immediately converted to a list of integer character Unicode code > points and stays that way as long as possible. > > The more I think about it the more I come to the conclusion that we > should not be writing polymorphic interfaces to libraries and making > them easy to use. Instead we should be writing minimal libraries > containing only essential features. This sounds right. Though I suspect you'll start to see a lot of "wrapper functions" emerge in the client code. I doubt as a library user you'd want to routinely write those. I tend to write as little code as possible and start to use it - then observe the patterns that emerge. If there's something that shows up consistently enough, I think that becomes a function, somewhere. If you love your users (and I know you do) you'll be nice and provide that function in your library :) > We should make our minds up about things like filenames, directory > names etc. representations and we should enforce them uniformly > accross all libraries. (My choice would be that filenames are always > represented by flat lists of Unicode integers, directory names always > have a trailing "/") etc. I think this will be hard to achieve in Erlangdom :) > Paradoxically the goal of making a particular library easy to use by > offering multiple polymorphic entry points not only makes it far more > difficult to understand, but difficult to compose the code in > different modules. Polymorphic data types muck up the type signatures > since the types of the polymorphic arguments tend to escape the module > and propagate silly types all over the place. I like libraries that are easy to use and wouldn't want to shift the burden to the caller, if you know how the caller will tend to use the library. You could accomplish both goals I think with two modules - one for the implementation, which is minimal and focused on maintainability, and another that focuses on usability issues. I might have done this once - I don't see the big trade offs that you're describing. Then again, I haven't looked for them. I will now - I think it's a very good observation and I'm sure there's a lot of code out there that could be dramatically simplified by separating these two concerns. > Note: a similar argument can be made for code that provides default > arguments to a generic function. Suppose we have an essential function > with seven arguments, should we provide half a dozen helper functions > that provide default arguments the the big function in different ways? I'm a fan of the getopt approach of separating truly essential arguments from optional arguments. Looking over lots of functions, I see there's usually zero to three truly essential args (on average, it seems) and the rest go into a proplist. That approach cuts down on the arity permutations, but doesn't say whether you're highly polymorphic or not. I think it eases the burden. > So am I right? - should we junk all the convenience functions in a > module and stick to essential functionality offering only one way to > do something? I like the idea of separating code that helps the user from code that implements the core functionality. I don't like the idea of pushing common patterns off on the user which in turn makes her code more complicated. That said... > I'll do this for a while and see what happens. This! Garrett From mononcqc@REDACTED Tue Mar 17 16:22:49 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 17 Mar 2015 11:22:49 -0400 Subject: [erlang-questions] A question of style In-Reply-To: References: Message-ID: <20150317152248.GC11827@ferdair.local> Great thread idea. My answers inline. On 03/17, Joe Armstrong wrote: > "adding lots of convenience interface functions to the library code > makes the library code difficult to understand" - it difficult to see > at a glance what the "essential functionality" of the library and to > distinguish the essential functionality from the convenience and > non-essential functions. > Yes and no. To some extent, "easy to use" in this context means "short to call", but you could very well (and probably should) define it as "easy to reason about". The complexity at that point is a bit about defining what your inputs and outputs are. If you allow everything to be an input for a restricted type of output, you now have to understand 1. the code 2. the mapping of all possible inputs to their intermediary representation (when modifying that module) Which has its cognitive overheads. So if you allow your parsing functions to accept integers and floats and binaries and lists and whatnot, you're making it more complex within that module. On the other hand, you can decide that your function, for strings, will accept: - lists of characters only - binaries only - iolists (lists of lists of characters and/or lists of binaries) - iodata (same as an iolist, but can also be a single binary And then you get to figure out encodings (chardata is an iolist but with codepoints! binaries can be utf8, utf16m utf32, but not codepoints!) In any case, as long as you can easily define a mapping between what you accept, to what you use as an internal data structure (if any) to what you output, then the code can be easier to modify. The user will always have the overhead of mapping the inputs to the outputs, and may or may not be left to guess what the intermediary format is when something surprising happens. If the internal mapping is good, the user will have a good time. > So is this true: > > easy to use the library == not easy to understand the library code > What I believe hurts is a series of ad-hoc mappings. You know the type where you go "oh sometimes the value is 'undefined' in my other module so I'll treat 'undefined' as an empty stream of characters". This one is bad. The question here again is not about 'ease of use' but about 'ease of inserting in my existing code flow' -- which is a very specific kind of use. It's making it easy to plug it into existing code rather than refactoring and rewriting existing code to know what kind of data it is carrying around. In fact, you're taking the decision related to handling some input in another module, and bringing it into an entirely different one. You've uprooted the decision from its context, and context is everything. *THIS* is what makes code hard to understand. The decision made about how to carry types of data around and how to interpret them is now spread everywhere around the program, and your modules, while sharing nothing in code, share a lot in assumptions and implicit meanings. This hurts. It's a meta-global variable, where you get to track a (now) global assumption, but without any keyword in the code to tell you so. > Example: File names; are they strings, binaries, atoms or deep-lists? > I guess you'll find all of these used in an inconsistent manner. > > This multiple representation of filenames seems to be an example of > chronic "can't make you mind up ism", is it a bird or a plane? I > dunno, it's both. > It can be that. The other is the good old stress between backwards and forwards compatibility, and supporting new features (multiple encodings, for example). > With directory names things get even worse - it's all the complexity > of a filename with the added problem of wondering whether or not the > directory name ended with a "/" or not. Half the code in the system > does, the other half doesn't :-) > use filename:join/1-2 for these! The pain comes from trying to be smart and handling this by hand. "/" is not even a good way to do it on Windows! filename:join and filename:split will let you merge and explode directory paths in platform-agnostic ways and wil make your life much easier. Treat it as an opaque data type that only file-related modules can understand when possible. Let the file modules handle the file-related stuff. 24> filename:split("/usr/local/bin"). ["/","usr","local","bin"] 25> filename:split("foo/bar"). ["foo","bar"] 26> filename:split("a:\\msdev\\include"). ["a:/","msdev","include"] 17> filename:join(["/usr", "local", "bin"]). "/usr/local/bin" 18> filename:join(["a/b///c/"]). "a/b/c" 19> filename:join(["B:a\\b///c/"]). % Windows "b:a/b/c" In this case the problem is possibly miscommunication of what is expected in the interface, but look at the library, and it makes things so much easier. > The result was library code that was far shorter and easier to > understand. I made a design decision to minimize the use of binaries > for string processing and only use lists of integers (on input I use > binaries and convert them to lists) on output I convert the lists to > binaries (but no messing in the middle of my code). Previously I have > a lot of code with binary_to_list and list_to_binary all over the > place - all my problems with utf8/latin1 etc. almost vanished. The > data comes in as a UTF8 binary (or something) but then gets > immediately converted to a list of integer character Unicode code > points and stays that way as long as possible. > Ah yes, that's another important principle. Do your data conversions as close to the edge of the system as possible, both for inputs and outputs. You can use a safe sanitized format within the system, but at the edge, you convert, validate, and shape it how you want. At the output, that's where you escape, reencode, convert, and so on. Do note though that binary_to_list will convert a utf8 binary into a sequence of bytes as a list -- which Erlang will handle as latin1. If you instead use unicode:characters_to_list (and unicode:characters_to_binary), you will have encoding-sensitive conversion and it will also make your life much easier. list_to_binary and binary_to_list are for sequences of bytes. The unicode module is for human-readable text. Again, this comes from subtle distinctions between lists, charlists, iolists, chardata, binaries, iodata, and so on. We have many types of 'character collections' that all look the same but behave very differently. Dialyzer and type annotations *can* help there, but that's one area where Erlang's dynamic typing hurts, and the way to compensate is through discipline and tagging things in tuples. > The more I think about it the more I come to the conclusion that we > should not be writing polymorphic interfaces to libraries and making > them easy to use. Instead we should be writing minimal libraries > containing only essential features. > Yes, and these are simpler to test, too. > We should make our minds up about things like filenames, directory > names etc. representations and we should enforce them uniformly > accross all libraries. (My choice would be that filenames are always > represented by flat lists of Unicode integers, directory names always > have a trailing "/") etc. > This is a trickier one, because ultimately we don't decide. The underlying OS and filesystems do, and sometimes, the inconsistencies across these is what bubbles up to our user level. You'll want a common abstraction, but also ways to bypass these directly (for efficiency reasons, or bypassing an abstraction on new systems), and then conjugate them with *our* abstractions (say the file_server / group leaders stuff) and this can lead to a complexity explosion. > Note: a similar argument can be made for code that provides default > arguments to a generic function. Suppose we have an essential function > with seven arguments, should we provide half a dozen helper functions > that provide default arguments the the big function in different ways? > No, in that specific case, a proplist (or even a map) is what you want. This lets the caller specify the elements they want, and some form of initialization function in the module expand them with the default values where required. This tends to limit the cognitive load a bit, at the cost of a well-defined 'here we convert from the user to the internal format' function. If this one is well-isolated, things are easier in my opinion. This is an example of that 'have a clear intermediary mapping' idea I mentioned earlier in this email. > So am I right? - should we junk all the convenience functions in a > module and stick to essential functionality offering only one way to > do something? > Yes. At least generally. That's the problem with that stuff. The recipe is good in the general case, but nothing beats having step 1 be: 1. Think very hard about your problem and what you want to accomplish. In general it will be good to think of all the inputs you think make sense to accept (the least the better), and all the ouputs you think you can have, and restrict your modules and their functions to that. It will be easier to test and reason about, and the long-term result will likely be a bunch of clearly defined components, attached together by some piece of code that does a lot of data conversions and pre- and post-condition checking. Of course, sooner or later we will all have made mistakes and we'll have to reconsider, but the number one attribute for me is really this: "how easy is it for me to later change my mind and replace this functionality by something else." Some complexity for data type conversions has to go somewhere, the question is where. Again, if you keep the glue code cleaner, it's gonna be easy to reason about, but all the conversions will be spread everywhere through the system, with interesting interactions. These days, I personally tend to favor keeping the glue code more complex, but the building blocks simpler. It does mean glue gets to change a lot, but that's when you want to be disciplined and keep these changes at the edges of the system. I know in your presentations (like most functional presentations), you describe functions (or modules, or OTP apps) as black boxes. One input, one output. The tricky question really is how hard do you want to think about the black box when you move it around or change things around it. I don't care that much how hard it is to plug things in it, I can always buy adapters, but I do end up caring a lot about how hard it is to understand the relationships between what I put in it and what I get out of it (and making sure it won't blow up in my face). If I think I can safely get rid of the box or change things around it, I'm happy because the black box can stay shut, and can safely remain a black box in my mind. If every time I get near the black box I have to open it and make sure everything is fine, even if it's really easy to plug *anything* in it, I get to spend a lot of time worrying whether I should even touch the box to begin with. And the more I get shy from that black box, the more I fear touching the things that touch the box. And as I shy away from entire subsystems, they slowly aggregate together and turn into Pandora's box, the one no one dares approach, and this is how legacy systems are born. Regards, Fred. From egil@REDACTED Tue Mar 17 17:38:25 2015 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 17 Mar 2015 17:38:25 +0100 Subject: [erlang-questions] Why does Dialyzer crash on this map? In-Reply-To: References: <54749C90.6000602@llaisdy.com> <5474BA4C.4030706@llaisdy.com> <547716F8.7010208@llaisdy.com> <4B9AEB77-A709-4D97-8EF2-8FE1AF5A4071@llaisdy.com> Message-ID: <55085881.3060508@erlang.org> On 2015-03-13 11:20, Ali Sabil wrote: > Has this been solved for 17.4? I am getting the same crash on a quite > large code base using 17.4.1 Do you have a minimized testcase that fails on maint? I couldn't reproduce it with dt or dt2. I'll add the missing map type in find_terminals. // Bj?rn-Egil > > Thanks, > Ali > > On Thu, Nov 27, 2014 at 10:05 PM, Ivan Uemlianin > wrote: > > Dear Bj?rn-Egil > > Thanks very much for your work and for reporting back. It looks > like good news (for me and for 18 at least). > > Best wishes > > Ivan > > -- > festina lente > > > On 27 Nov 2014, at 20:52, Bj?rn-Egil Dahlberg > > wrote: > >> Looks like the regression was introduced in >> 'hb/dialyzer/fix_recognition_of_records/OTP-11935' >> (805f9c89fc01220bc1bb0f27e1b68fd4eca688ba) included from OTP 17.1 >> >> This becomes a none-issue in the master branch (for 18) since >> variables are allowed as keys there but it needs to be solved for >> the 17 track. >> >> >> 2014-11-27 21:13 GMT+01:00 Bj?rn-Egil Dahlberg >> >: >> >> I managed to reproduce your errors on dt.erl and dt2.erl >> using OTP-17.3.3 tag. >> >> Seems like I've missed something in dataflow .. looks like a >> clause missing for the map type. >> I'm not well versed in dialyzer. Hopefully I can do a fix for >> it for 17.4. >> >> There are a bit more stuff going on here too. When dialyzer >> uses the erlang compiler to compile to core >> it does not coalesce things to literals but keeps them >> abstract instead .. >> Compound keys such as [1,2,3] and {4,5,6} will thus become >> non-literals (variables) and such keys are not allowed in maps. >> >> I need to ponder that a bit before I try to solve it. >> >> // Bj?rn-Egil >> >> 2014-11-27 13:20 GMT+01:00 Ivan Uemlianin > >: >> >> Dear Dave >> >> Thanks for your help. Here are some more details: >> >> >> *** OS: FreeBSD 10.0-RELEASE >> >> $ uname -a >> FreeBSD simba 10.0-RELEASE FreeBSD 10.0-RELEASE #0 >> r260789: Thu Jan 16 22:34:59 UTC 2014 >> root@REDACTED >> :/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> Upgrading to 10.1 is on my todo list. >> >> >> *** Erlang version now 17.3_3,3 >> >> $ pkg info erlang >> erlang-17.3_1,3 >> ... >> $ sudo pkg upgrade >> ... >> >> $ pkg info erlang >> erlang-17.3_3,3 >> ... >> >> >> *** Errors persist >> >> Upgrading erlang has not changed behaviour. >> >> A couple more observations: >> >> 1. Running dialyzer on the module dt below gets the error >> as noted previously. However, if I uncomment the '%% ok' >> line, dialyzer will process the module with no problems. >> >> -module(dt). >> -export([get_map/0]). >> >> -spec get_map() -> map(). >> get_map() -> >> #{labels => [one, two], >> number => 27, >> %% [1,2,3] => wer, %% ok >> kvok => #{ >> a => qwe, >> 2 => asd, >> [1,2,3] => wer, %% bad >> {4,5,6} => sdf, %% bad >> "abc" => zxc >> } >> }. >> >> $ dialyzer dt.erl >> Checking whether the PLT /home/ivan/.dialyzer_plt >> is up-to-date... yes >> Proceeding with analysis... >> =ERROR REPORT==== 27-Nov-2014::12:17:02 === >> Error in process <0.45.0> with exit value: >> {{case_clause,map},[{dialyzer_dataflow,find_terminals,1,[{file,"dialyzer_dataflow.erl"},{line,3451}]},{dialyzer_dataflow,find_terminals_list,3,[{file,"dialyzer_dataflow.erl"},{line,3504}]},{dialyzer_dataflow,classify_returns... >> >> >> >> dialyzer: Analysis failed with error: >> {{case_clause,map}, >> [{dialyzer_dataflow,find_terminals,1, >> [{file,"dialyzer_dataflow.erl"},{line,3451}]}, >> {dialyzer_dataflow,find_terminals_list,3, >> [{file,"dialyzer_dataflow.erl"},{line,3504}]}, >> {dialyzer_dataflow,classify_returns,1, >> [{file,"dialyzer_dataflow.erl"},{line,3443}]}, >> {dialyzer_dataflow,'-state__get_warnings/2-fun-0-',7, >> [{file,"dialyzer_dataflow.erl"},{line,2908}]}, >> {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, >> {dialyzer_dataflow,state__get_warnings,2, >> [{file,"dialyzer_dataflow.erl"},{line,2934}]}, >> {dialyzer_dataflow,get_warnings,5, >> [{file,"dialyzer_dataflow.erl"},{line,142}]}, >> {dialyzer_succ_typings,collect_warnings,2, >> [{file,"dialyzer_succ_typings.erl"},{line,182}]}]} >> Last messages in the log cache: >> Reading files and computing callgraph... done in >> 0.07 secs >> Removing edges... done in 0.00 secs >> >> >> 2. Running dialyzer on the module dt2 below raises the >> warning following. Uncommenting the '%% ok' line has no >> effect. >> >> -module(dt2). >> -export([get_map/0]). >> >> -spec get_map() -> map(). >> get_map() -> >> X = #{labels => [one, two], >> number => 27, >> %% [1,2,3] => wer, %% ok >> kvok => #{ >> a => qwe, >> 2 => asd, >> [1,2,3] => wer, %% bad >> {4,5,6} => sdf, %% bad >> "abc" => zxc >> } >> }, >> X. >> >> $ dialyzer dt2.erl >> Checking whether the PLT /home/ivan/.dialyzer_plt >> is up-to-date... yes >> Proceeding with analysis... >> dt2.erl:5: Function get_map/0 has no local return >> done in 0m0.41s >> done (warnings were emitted) >> >> Best wishes >> >> Ivan >> >> >> >> >> On 11/25/14 20:37, Dave Cottlehuber wrote: >> >> Sorry about that last email ? >> >> EWORKSFORME. >> >> FreeBSD 10.1 amd64, erlang-17.3_2,3 from pkg. >> >> What FreeBSD & erlang are you using? >> >> dch /tmp ??? dialyzer --build_plt --apps erts >> kernel stdlib >> Creating PLT /home/dch/.dialyzer_plt ... >> Unknown functions: >> compile:file/2 >> compile:forms/2 >> compile:noenv_forms/2 >> compile:output_generated/1 >> crypto:block_decrypt/4 >> crypto:start/0 >> Unknown types: >> compile:option/0 >> done in 1m8.53s >> done (passed successfully) >> >> dch /tmp ???dialyzer ltu.erl >> Checking whether the PLT /home/dch/.dialyzer_plt >> is up-to-date... yes >> Proceeding with analysis... done in 0m0.41s >> done (passed successfully) >> >> dch /tmp ???erl >> Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] >> [async-threads:64] [kernel-poll:true] >> >> Eshell V6.2 (abort with ^G) >> 1> >> >> A+, Dave >> ? sent from my Couch >> >> >> _______________________________________________ >> 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 >> @llaisdy >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> >> festina lente >> ============================================================ >> >> _______________________________________________ >> 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 hanasim@REDACTED Tue Mar 17 20:42:12 2015 From: hanasim@REDACTED (Manju Hanasi) Date: Wed, 18 Mar 2015 01:12:12 +0530 Subject: [erlang-questions] fd=NN is larger than the largest allowed fd=255 Message-ID: Hi, We are using an older version of Couchbase Mobile on Android and this one is erlang based. We use OTP version R14B03. I know it's pretty old and it's time to upgrade, so bare with me. Recently we have started getting errors like "fd=NN is larger than the largest allowed fd=255" where NN is any value greater than 255. This is not really an OS limitation as the 'ulimit -a' on Android shows 1024 for open file descriptors (as found out by 'adb shell'). Looks like Erlang VM is not allowing file descriptors more than 255. It would be great if we could set some environment variable or pass a parameter that can increase this limit (e.g. https://github.com/couchbase/Android-Couchbase/blob/master/src/com/couchbase/android/CouchbaseService.java#L203 ). We tried setting "ERL_MAX_PORTS" environment variable to 1024, but we still get the error at 255. Unfortunately, our version doesn't support +Q parameter for increasing the number of ports. Is there any quick and/or hacky way to increase the fd limit beyond 255; for example increase it to 512 or 1024? I greatly appreciate any help in resolving this issue. Thanks Manju -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Tue Mar 17 21:42:06 2015 From: garazdawi@REDACTED (Lukas Larsson) Date: Tue, 17 Mar 2015 21:42:06 +0100 Subject: [erlang-questions] fd=NN is larger than the largest allowed fd=255 In-Reply-To: References: Message-ID: Hello, I believe that that limitation is determined by this piece of code: https://github.com/erlang/otp/blob/maint/erts/emulator/sys/common/erl_poll.c#L2308-L2320 So you have to figure what is defined on Android and check that. Basho has a guide which tells you some of the more common places to look for what could be causing this limit: http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/. I would first check sysconf and make sure that you are allowed to open as many fd's as you want. Lukas On Tue, Mar 17, 2015 at 8:42 PM, Manju Hanasi wrote: > Hi, > > We are using an older version of Couchbase Mobile on Android and this one > is erlang based. We use OTP version R14B03. I know it's pretty old and it's > time to upgrade, so bare with me. > > Recently we have started getting errors like "fd=NN is larger than the > largest allowed fd=255" where NN is any value greater than 255. > > This is not really an OS limitation as the 'ulimit -a' on Android shows > 1024 for open file descriptors (as found out by 'adb shell'). > > Looks like Erlang VM is not allowing file descriptors more than 255. > > It would be great if we could set some environment variable or pass a > parameter that can increase this limit (e.g. > https://github.com/couchbase/Android-Couchbase/blob/master/src/com/couchbase/android/CouchbaseService.java#L203 > ). > > We tried setting "ERL_MAX_PORTS" environment variable to 1024, but we > still get the error at 255. > > Unfortunately, our version doesn't support +Q parameter for increasing the > number of ports. > > Is there any quick and/or hacky way to increase the fd limit beyond 255; > for example increase it to 512 or 1024? > > I greatly appreciate any help in resolving this issue. > > Thanks > Manju > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me@REDACTED Tue Mar 17 22:51:22 2015 From: me@REDACTED (Leandro Ostera) Date: Tue, 17 Mar 2015 18:51:22 -0300 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: <20150317142651.GB11827@ferdair.local> References: <55083530.2070108@ninenines.eu> <20150317142651.GB11827@ferdair.local> Message-ID: Is there any sort of centralized repository for this? Coming from the Node.js world, we have npm (with all it's faults and flaws). Npm doesn't use git for versioning. Git history can be rewritten, and anyone can remove (semver) release tags, so it's kinda pointless. Scenario: I request extend/cowboy.git#0.9, the people at extend overwrite the 0.9 tag and then the next time I'm pulling that repo, I'll get a different version of the library. This of course does not aid in deterministic builds. On the other hand, by using npm, regardless of whether you store your code (github, bitbucket, locally), you publish a release from your current computer and it basically uploads a tarball. Sure you can keep track of release numbers using git tags too, but everyone can get any published version. Fundamental to deterministic builds is not being able to *republish* under a version name. Which obligues you to increment your semver with every fix, feature, and major overhaul. So if there was something like an erlang package manager ?epm?? (I've seen agner/agner but seems very outdated), anyone could specify the module name and release version in rebar, and rebar would talk to these service instead and get exactly what it needs, instead of relying on a variable data-source. This approach has long helped the node community to collaborate and share modules more easily, and in a community where every week there's a new build tool (grunt, gulp, broccoli, jake, and a billion more) npm has remained a constant factor from the very early days. In any case, I'd be interested in learning more of what's currently available for erlang to deal with this issues, so any pointers are very much welcomed :) On Tue, Mar 17, 2015 at 11:26 AM, Fred Hebert wrote: > On 03/17, Lo?c Hoguin wrote: > > I believe rebar3 has a way to lock dependencies into a specific commit > for > > the projects that depend on another's "master". > > Yes. It's done automatically when compiling, building releases, or any > other command that depends on compiled modules being there (an explicit > `rebar3 lock' command can be run too). > > --- > > Another answer that Joe might want is the possibility of using releases. > Whether it's with systools, reltool, relx (possibly via erlang.mk or > rebar3), releases allow you to ship an Erlang program with its minimal > version of the Erlang VM, with the code pre-compiled. > > This at least removes the requirement that the user has Erlang or make > installed, and makes it so Joe (or the release creator) used a similar > runtime system to compile the application, or took specific steps to > cross-compile. > > Releases also have the option to ship without stdlibs or the ERTS in > case you want them to run on a target system with an existing copy of > Erlang in there. > > If the code uses no NIFs, such portable releases are really the best way > to go about distributing Erlang code. > > The big constraint is that you must write OTP applications for these to > work, which I know Joe sometimes likes not to do (a supervisor bridge > may help such cases: http://www.erlang.org/doc/man/supervisor_bridge.html > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Leandro Ostera Github | LinkedIn | Facebook | @leostera -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjsvance@REDACTED Tue Mar 17 23:56:21 2015 From: cjsvance@REDACTED (Christopher Vance) Date: Wed, 18 Mar 2015 09:56:21 +1100 Subject: [erlang-questions] A question of style In-Reply-To: <20150317152248.GC11827@ferdair.local> References: <20150317152248.GC11827@ferdair.local> Message-ID: My take on Joe's original email was that I would have preferred (going back before my_lib was created): -module(my_lib). -export([parse/1]). parse(Binary) when is_binary(Binary) -> ...; parse(String) when is_list(String) -> .... That way the implementation gets to decide which function clauses get done in terms of others, and which are basic enough to have an implementation which doesn't pass the buck elsewhere. But of course, that wasn't the question, and with an existing library it's not always possible to refactor like that. On Wed, Mar 18, 2015 at 2:22 AM, Fred Hebert wrote: > Great thread idea. My answers inline. > > On 03/17, Joe Armstrong wrote: > > "adding lots of convenience interface functions to the library code > > makes the library code difficult to understand" - it difficult to see > > at a glance what the "essential functionality" of the library and to > > distinguish the essential functionality from the convenience and > > non-essential functions. > > > > Yes and no. To some extent, "easy to use" in this context means "short > to call", but you could very well (and probably should) define it as > "easy to reason about". > > The complexity at that point is a bit about defining what your inputs > and outputs are. If you allow everything to be an input for a restricted > type of output, you now have to understand > > 1. the code > 2. the mapping of all possible inputs to their intermediary > representation (when modifying that module) > > Which has its cognitive overheads. So if you allow your parsing > functions to accept integers and floats and binaries and lists and > whatnot, you're making it more complex within that module. > > On the other hand, you can decide that your function, for strings, will > accept: > > - lists of characters only > - binaries only > - iolists (lists of lists of characters and/or lists of binaries) > - iodata (same as an iolist, but can also be a single binary > > And then you get to figure out encodings (chardata is an iolist but with > codepoints! binaries can be utf8, utf16m utf32, but not codepoints!) > > In any case, as long as you can easily define a mapping between what you > accept, to what you use as an internal data structure (if any) to what > you output, then the code can be easier to modify. > > The user will always have the overhead of mapping the inputs to the > outputs, and may or may not be left to guess what the intermediary > format is when something surprising happens. If the internal mapping is > good, the user will have a good time. > > > So is this true: > > > > easy to use the library == not easy to understand the library code > > > > What I believe hurts is a series of ad-hoc mappings. You know the type > where you go "oh sometimes the value is 'undefined' in my other module > so I'll treat 'undefined' as an empty stream of characters". > > This one is bad. The question here again is not about 'ease of use' but > about 'ease of inserting in my existing code flow' -- which is a very > specific kind of use. > > It's making it easy to plug it into existing code rather than > refactoring and rewriting existing code to know what kind of data it is > carrying around. In fact, you're taking the decision related to handling > some input in another module, and bringing it into an entirely different > one. You've uprooted the decision from its context, and context is > everything. > > *THIS* is what makes code hard to understand. The decision made about > how to carry types of data around and how to interpret them is now > spread everywhere around the program, and your modules, while sharing > nothing in code, share a lot in assumptions and implicit meanings. > > This hurts. It's a meta-global variable, where you get to track a (now) > global assumption, but without any keyword in the code to tell you so. > > > Example: File names; are they strings, binaries, atoms or deep-lists? > > I guess you'll find all of these used in an inconsistent manner. > > > > This multiple representation of filenames seems to be an example of > > chronic "can't make you mind up ism", is it a bird or a plane? I > > dunno, it's both. > > > > It can be that. The other is the good old stress between backwards and > forwards compatibility, and supporting new features (multiple encodings, > for example). > > > With directory names things get even worse - it's all the complexity > > of a filename with the added problem of wondering whether or not the > > directory name ended with a "/" or not. Half the code in the system > > does, the other half doesn't :-) > > > > use filename:join/1-2 for these! The pain comes from trying to be smart > and handling this by hand. "/" is not even a good way to do it on > Windows! filename:join and filename:split will let you merge and explode > directory paths in platform-agnostic ways and wil make your life much > easier. Treat it as an opaque data type that only file-related modules > can understand when possible. Let the file modules handle the > file-related stuff. > > 24> filename:split("/usr/local/bin"). > ["/","usr","local","bin"] > 25> filename:split("foo/bar"). > ["foo","bar"] > 26> filename:split("a:\\msdev\\include"). > ["a:/","msdev","include"] > > 17> filename:join(["/usr", "local", "bin"]). > "/usr/local/bin" > 18> filename:join(["a/b///c/"]). > "a/b/c" > 19> filename:join(["B:a\\b///c/"]). % Windows > "b:a/b/c" > > In this case the problem is possibly miscommunication of what is > expected in the interface, but look at the library, and it makes things > so much easier. > > > > The result was library code that was far shorter and easier to > > understand. I made a design decision to minimize the use of binaries > > for string processing and only use lists of integers (on input I use > > binaries and convert them to lists) on output I convert the lists to > > binaries (but no messing in the middle of my code). Previously I have > > a lot of code with binary_to_list and list_to_binary all over the > > place - all my problems with utf8/latin1 etc. almost vanished. The > > data comes in as a UTF8 binary (or something) but then gets > > immediately converted to a list of integer character Unicode code > > points and stays that way as long as possible. > > > > Ah yes, that's another important principle. Do your data conversions as > close to the edge of the system as possible, both for inputs and > outputs. You can use a safe sanitized format within the system, but at > the edge, you convert, validate, and shape it how you want. At the > output, that's where you escape, reencode, convert, and so on. > > Do note though that binary_to_list will convert a utf8 binary into a > sequence of bytes as a list -- which Erlang will handle as latin1. If > you instead use unicode:characters_to_list (and > unicode:characters_to_binary), you will have encoding-sensitive > conversion and it will also make your life much easier. list_to_binary > and binary_to_list are for sequences of bytes. The unicode module is for > human-readable text. > > Again, this comes from subtle distinctions between lists, charlists, > iolists, chardata, binaries, iodata, and so on. We have many types of > 'character collections' that all look the same but behave very > differently. Dialyzer and type annotations *can* help there, but that's > one area where Erlang's dynamic typing hurts, and the way to compensate > is through discipline and tagging things in tuples. > > > The more I think about it the more I come to the conclusion that we > > should not be writing polymorphic interfaces to libraries and making > > them easy to use. Instead we should be writing minimal libraries > > containing only essential features. > > > > Yes, and these are simpler to test, too. > > > We should make our minds up about things like filenames, directory > > names etc. representations and we should enforce them uniformly > > accross all libraries. (My choice would be that filenames are always > > represented by flat lists of Unicode integers, directory names always > > have a trailing "/") etc. > > > > This is a trickier one, because ultimately we don't decide. The > underlying OS and filesystems do, and sometimes, the inconsistencies > across these is what bubbles up to our user level. You'll want a common > abstraction, but also ways to bypass these directly (for efficiency > reasons, or bypassing an abstraction on new systems), and then > conjugate them with *our* abstractions (say the file_server / group > leaders stuff) and this can lead to a complexity explosion. > > > Note: a similar argument can be made for code that provides default > > arguments to a generic function. Suppose we have an essential function > > with seven arguments, should we provide half a dozen helper functions > > that provide default arguments the the big function in different ways? > > > > No, in that specific case, a proplist (or even a map) is what you want. > This lets the caller specify the elements they want, and some form of > initialization function in the module expand them with the default > values where required. This tends to limit the cognitive load a bit, at > the cost of a well-defined 'here we convert from the user to the > internal format' function. If this one is well-isolated, things are > easier in my opinion. > > This is an example of that 'have a clear intermediary mapping' idea I > mentioned earlier in this email. > > > So am I right? - should we junk all the convenience functions in a > > module and stick to essential functionality offering only one way to > > do something? > > > > Yes. At least generally. That's the problem with that stuff. The recipe > is good in the general case, but nothing beats having step 1 be: > > 1. Think very hard about your problem and what you want to accomplish. > > In general it will be good to think of all the inputs you think make > sense to accept (the least the better), and all the ouputs you think you > can have, and restrict your modules and their functions to that. It will > be easier to test and reason about, and the long-term result will likely > be a bunch of clearly defined components, attached together by some > piece of code that does a lot of data conversions and pre- and > post-condition checking. > > Of course, sooner or later we will all have made mistakes and we'll have > to reconsider, but the number one attribute for me is really this: "how > easy is it for me to later change my mind and replace this functionality > by something else." Some complexity for data type conversions has to go > somewhere, the question is where. > > Again, if you keep the glue code cleaner, it's gonna be easy to reason > about, but all the conversions will be spread everywhere through the > system, with interesting interactions. These days, I personally tend to > favor keeping the glue code more complex, but the building blocks > simpler. > > It does mean glue gets to change a lot, but that's when you want to be > disciplined and keep these changes at the edges of the system. > > I know in your presentations (like most functional presentations), you > describe functions (or modules, or OTP apps) as black boxes. One input, > one output. The tricky question really is how hard do you want to think > about the black box when you move it around or change things around it. > > I don't care that much how hard it is to plug things in it, I can always > buy adapters, but I do end up caring a lot about how hard it is to > understand the relationships between what I put in it and what I get out > of it (and making sure it won't blow up in my face). If I think I can > safely get rid of the box or change things around it, I'm happy because > the black box can stay shut, and can safely remain a black box in my > mind. > > If every time I get near the black box I have to open it and make sure > everything is fine, even if it's really easy to plug *anything* in it, I > get to spend a lot of time worrying whether I should even touch the box > to begin with. > > And the more I get shy from that black box, the more I fear touching the > things that touch the box. And as I shy away from entire subsystems, > they slowly aggregate together and turn into Pandora's box, the one no > one dares approach, and this is how legacy systems are born. > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Christopher Vance -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyarly@REDACTED Wed Mar 18 00:14:10 2015 From: nyarly@REDACTED (Judson Lester) Date: Tue, 17 Mar 2015 23:14:10 +0000 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: <55083530.2070108@ninenines.eu> <20150317142651.GB11827@ferdair.local> Message-ID: On Tue, Mar 17, 2015 at 2:51 PM Leandro Ostera wrote: > Is there any sort of centralized repository for this? > Not to open a can of worms again, but this is the question that a centralized package repository is designed to address. I think releases are a fab way to distribute complete erlang applications (even as I'm still digesting the implications of that), but I'm not as convinced about using them to distribute libraries. OTP has been the way that Erlang libs get distributed for a long time, from what I understand, but there are a number of use cases that aren't general enough to be included in OTP, or where there's very active work in a problem space (e.g. pooling). Judson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Wed Mar 18 05:36:45 2015 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Tue, 17 Mar 2015 21:36:45 -0700 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: <55083530.2070108@ninenines.eu> <20150317142651.GB11827@ferdair.local> Message-ID: <550900DD.3000302@gmail.com> On 03/17/2015 02:51 PM, Leandro Ostera wrote: > Scenario: > > I request extend/cowboy.git#0.9, the people at extend overwrite the 0.9 tag > and then the next time > I'm pulling that repo, I'll get a different version of the library. This of > course does not aid in > deterministic builds. In every SCM I've used, tags can be renamed and moved at will. IMHO, someone who's *actually* interested in deterministic builds should use the immutable info provided by their SCM (revision # for SVN, commit hash for git, etc.) rather than something that can be changed at any time. I would be surprised if 'rebar3 lock' didn't convert references to tags into references to commit hashes. Also note that when someone rewrites git history, all of the affected commit hashes are changed. This means that build systems that use commit hashes, rather than named tags won't be affected by a history rewrite. (Unless -of course- the referenced commit is removed.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ulf@REDACTED Wed Mar 18 09:28:20 2015 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 18 Mar 2015 09:28:20 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550831B9.2000505@meetinghouse.net> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> Message-ID: > On 17 Mar 2015, at 14:52, Miles Fidelman wrote: > > That which is hateful to you, do not unto another This is great advice. Some time ago, I watched a lecture by Greg Lukianoff [1] on the defense of Free Speech on American campuses. Apparently, it has become common practice to have Free Speech Zones [2], where you are *allowed* to exercise your 1st Amendmend Rights. Normally, you need to book a slot in the zone in advance. I think many of us have been taken aback by this apparent clash of principles: The Right to Express your Opinion vs. The Right Not to be Offended. Disregarding political/religious convictions, I think we can agree as engineers that these two principles are incompatible. However, the conflict is not apparent as long as people do what most do: strive not to deliberately offend. One can at least say that the former principle is more in line with the Erlang philosophy of asynchronous communication, where no guarantees are offered regarding whether the message will be received at all, or what will happen upon reception. Because of this, Erlang processes must be prepared to receive messages they don?t understand or want, and good style suggests that you should strive to communicate responsibly and use asynchronous messaging with care. There are very solid reasons for this. Needless to say, there are some aspects of Erlang communication that don?t transfer well onto communication between humans, but this only shows that the relationship is not commutable. Principles that are clearly untenable in software design, are likely problematic in human activities as well. BR, Ulf W [1] https://www.youtube.com/watch?v=Autfo3H6Dss [2] http://en.wikipedia.org/wiki/Free_speech_zone Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From davidnwelton@REDACTED Wed Mar 18 10:34:48 2015 From: davidnwelton@REDACTED (David Welton) Date: Wed, 18 Mar 2015 10:34:48 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: <550900DD.3000302@gmail.com> References: <55083530.2070108@ninenines.eu> <20150317142651.GB11827@ferdair.local> <550900DD.3000302@gmail.com> Message-ID: > In every SCM I've used, tags can be renamed and moved at will. There is probably an argument to be made that using code from people who push tags and then subsequently fiddle with them is probably a bad idea in other ways too. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From ulf@REDACTED Wed Mar 18 11:01:20 2015 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 18 Mar 2015 11:01:20 +0100 Subject: [erlang-questions] A question of style In-Reply-To: <20150317152248.GC11827@ferdair.local> References: <20150317152248.GC11827@ferdair.local> Message-ID: <06113B03-898F-4FE8-B9D3-0651F98704E2@feuerlabs.com> > On 17 Mar 2015, at 16:22, Fred Hebert wrote: > > *THIS* is what makes code hard to understand. The decision made about > how to carry types of data around and how to interpret them is now > spread everywhere around the program, and your modules, while sharing > nothing in code, share a lot in assumptions and implicit meanings. Of course, at one extreme, you need only one function: eval(Binary) BR, Ulf W ;-) Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From ali.sabil@REDACTED Wed Mar 18 12:01:36 2015 From: ali.sabil@REDACTED (Ali Sabil) Date: Wed, 18 Mar 2015 12:01:36 +0100 Subject: [erlang-questions] Why does Dialyzer crash on this map? In-Reply-To: <55085881.3060508@erlang.org> References: <54749C90.6000602@llaisdy.com> <5474BA4C.4030706@llaisdy.com> <547716F8.7010208@llaisdy.com> <4B9AEB77-A709-4D97-8EF2-8FE1AF5A4071@llaisdy.com> <55085881.3060508@erlang.org> Message-ID: I tried to create a minimal testcase but I unfortunately haven't been able to. I was running dialyzer on a quite large code base and now even the unpatched dialyzer works without any issue after I fixed all the issues reported by dialyzer. On Tue, Mar 17, 2015 at 5:38 PM, Bj?rn-Egil Dahlberg wrote: > On 2015-03-13 11:20, Ali Sabil wrote: > > Has this been solved for 17.4? I am getting the same crash on a quite > large code base using 17.4.1 > > > Do you have a minimized testcase that fails on maint? I couldn't reproduce > it with dt or dt2. > > I'll add the missing map type in find_terminals. > > // Bj?rn-Egil > > > > Thanks, > Ali > > On Thu, Nov 27, 2014 at 10:05 PM, Ivan Uemlianin wrote: > >> Dear Bj?rn-Egil >> >> Thanks very much for your work and for reporting back. It looks like >> good news (for me and for 18 at least). >> >> Best wishes >> >> Ivan >> >> -- >> festina lente >> >> >> On 27 Nov 2014, at 20:52, Bj?rn-Egil Dahlberg < >> wallentin.dahlberg@REDACTED> wrote: >> >> Looks like the regression was introduced in >> 'hb/dialyzer/fix_recognition_of_records/OTP-11935' >> (805f9c89fc01220bc1bb0f27e1b68fd4eca688ba) included from OTP 17.1 >> >> This becomes a none-issue in the master branch (for 18) since variables >> are allowed as keys there but it needs to be solved for the 17 track. >> >> >> 2014-11-27 21:13 GMT+01:00 Bj?rn-Egil Dahlberg < >> wallentin.dahlberg@REDACTED>: >> >>> I managed to reproduce your errors on dt.erl and dt2.erl using >>> OTP-17.3.3 tag. >>> >>> Seems like I've missed something in dataflow .. looks like a clause >>> missing for the map type. >>> I'm not well versed in dialyzer. Hopefully I can do a fix for it for >>> 17.4. >>> >>> There are a bit more stuff going on here too. When dialyzer uses the >>> erlang compiler to compile to core >>> it does not coalesce things to literals but keeps them abstract instead >>> .. >>> Compound keys such as [1,2,3] and {4,5,6} will thus become non-literals >>> (variables) and such keys are not allowed in maps. >>> >>> I need to ponder that a bit before I try to solve it. >>> >>> // Bj?rn-Egil >>> >>> 2014-11-27 13:20 GMT+01:00 Ivan Uemlianin : >>> >>>> Dear Dave >>>> >>>> Thanks for your help. Here are some more details: >>>> >>>> >>>> *** OS: FreeBSD 10.0-RELEASE >>>> >>>> $ uname -a >>>> FreeBSD simba 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 >>>> 22:34:59 UTC 2014 root@REDACTED:/usr/obj/usr/src/sys/GENERIC >>>> amd64 >>>> >>>> Upgrading to 10.1 is on my todo list. >>>> >>>> >>>> *** Erlang version now 17.3_3,3 >>>> >>>> $ pkg info erlang >>>> erlang-17.3_1,3 >>>> ... >>>> $ sudo pkg upgrade >>>> ... >>>> >>>> $ pkg info erlang >>>> erlang-17.3_3,3 >>>> ... >>>> >>>> >>>> *** Errors persist >>>> >>>> Upgrading erlang has not changed behaviour. >>>> >>>> A couple more observations: >>>> >>>> 1. Running dialyzer on the module dt below gets the error as noted >>>> previously. However, if I uncomment the '%% ok' line, dialyzer will >>>> process the module with no problems. >>>> >>>> -module(dt). >>>> -export([get_map/0]). >>>> >>>> -spec get_map() -> map(). >>>> get_map() -> >>>> #{labels => [one, two], >>>> number => 27, >>>> %% [1,2,3] => wer, %% ok >>>> kvok => #{ >>>> a => qwe, >>>> 2 => asd, >>>> [1,2,3] => wer, %% bad >>>> {4,5,6} => sdf, %% bad >>>> "abc" => zxc >>>> } >>>> }. >>>> >>>> $ dialyzer dt.erl >>>> Checking whether the PLT /home/ivan/.dialyzer_plt is >>>> up-to-date... yes >>>> Proceeding with analysis... >>>> =ERROR REPORT==== 27-Nov-2014::12:17:02 === >>>> Error in process <0.45.0> with exit value: >>>> {{case_clause,map},[{dialyzer_dataflow,find_terminals,1,[{file,"dialyzer_dataflow.erl"},{line,3451}]},{dialyzer_dataflow,find_terminals_list,3,[{file,"dialyzer_dataflow.erl"},{line,3504}]},{dialyzer_dataflow,classify_returns... >>>> >>>> >>>> >>>> dialyzer: Analysis failed with error: >>>> {{case_clause,map}, >>>> [{dialyzer_dataflow,find_terminals,1, >>>> [{file,"dialyzer_dataflow.erl"},{line,3451}]}, >>>> {dialyzer_dataflow,find_terminals_list,3, >>>> [{file,"dialyzer_dataflow.erl"},{line,3504}]}, >>>> {dialyzer_dataflow,classify_returns,1, >>>> [{file,"dialyzer_dataflow.erl"},{line,3443}]}, >>>> {dialyzer_dataflow,'-state__get_warnings/2-fun-0-',7, >>>> [{file,"dialyzer_dataflow.erl"},{line,2908}]}, >>>> {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, >>>> {dialyzer_dataflow,state__get_warnings,2, >>>> [{file,"dialyzer_dataflow.erl"},{line,2934}]}, >>>> {dialyzer_dataflow,get_warnings,5, >>>> [{file,"dialyzer_dataflow.erl"},{line,142}]}, >>>> {dialyzer_succ_typings,collect_warnings,2, >>>> [{file,"dialyzer_succ_typings.erl"},{line,182}]}]} >>>> Last messages in the log cache: >>>> Reading files and computing callgraph... done in 0.07 secs >>>> Removing edges... done in 0.00 secs >>>> >>>> >>>> 2. Running dialyzer on the module dt2 below raises the warning >>>> following. Uncommenting the '%% ok' line has no effect. >>>> >>>> -module(dt2). >>>> -export([get_map/0]). >>>> >>>> -spec get_map() -> map(). >>>> get_map() -> >>>> X = #{labels => [one, two], >>>> number => 27, >>>> %% [1,2,3] => wer, %% ok >>>> kvok => #{ >>>> a => qwe, >>>> 2 => asd, >>>> [1,2,3] => wer, %% bad >>>> {4,5,6} => sdf, %% bad >>>> "abc" => zxc >>>> } >>>> }, >>>> X. >>>> >>>> $ dialyzer dt2.erl >>>> Checking whether the PLT /home/ivan/.dialyzer_plt is >>>> up-to-date... yes >>>> Proceeding with analysis... >>>> dt2.erl:5: Function get_map/0 has no local return >>>> done in 0m0.41s >>>> done (warnings were emitted) >>>> >>>> Best wishes >>>> >>>> Ivan >>>> >>>> >>>> >>>> >>>> On 11/25/14 20:37, Dave Cottlehuber wrote: >>>> >>>>> Sorry about that last email ? >>>>> >>>>> EWORKSFORME. >>>>> >>>>> FreeBSD 10.1 amd64, erlang-17.3_2,3 from pkg. >>>>> >>>>> What FreeBSD & erlang are you using? >>>>> >>>>> dch /tmp ??? dialyzer --build_plt --apps erts kernel stdlib >>>>> Creating PLT /home/dch/.dialyzer_plt ... >>>>> Unknown functions: >>>>> compile:file/2 >>>>> compile:forms/2 >>>>> compile:noenv_forms/2 >>>>> compile:output_generated/1 >>>>> crypto:block_decrypt/4 >>>>> crypto:start/0 >>>>> Unknown types: >>>>> compile:option/0 >>>>> done in 1m8.53s >>>>> done (passed successfully) >>>>> >>>>> dch /tmp ???dialyzer ltu.erl >>>>> Checking whether the PLT /home/dch/.dialyzer_plt is up-to-date... >>>>> yes >>>>> Proceeding with analysis... done in 0m0.41s >>>>> done (passed successfully) >>>>> >>>>> dch /tmp ???erl >>>>> Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] >>>>> [async-threads:64] [kernel-poll:true] >>>>> >>>>> Eshell V6.2 (abort with ^G) >>>>> 1> >>>>> >>>>> A+, Dave >>>>> ? sent from my Couch >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> @llaisdy >>>> llaisdy.wordpress.com >>>> github.com/llaisdy >>>> www.linkedin.com/in/ivanuemlianin >>>> >>>> festina lente >>>> ============================================================ >>>> >>>> _______________________________________________ >>>> 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 listerlang-questions@REDACTED://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 egil@REDACTED Wed Mar 18 12:12:14 2015 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Wed, 18 Mar 2015 12:12:14 +0100 Subject: [erlang-questions] Why does Dialyzer crash on this map? In-Reply-To: References: <54749C90.6000602@llaisdy.com> <5474BA4C.4030706@llaisdy.com> <547716F8.7010208@llaisdy.com> <4B9AEB77-A709-4D97-8EF2-8FE1AF5A4071@llaisdy.com> <55085881.3060508@erlang.org> Message-ID: <55095D8E.2050103@erlang.org> On 2015-03-18 12:01, Ali Sabil wrote: > I tried to create a minimal testcase but I unfortunately haven't been > able to. I was running dialyzer on a quite large code base and now > even the unpatched dialyzer works without any issue after I fixed all > the issues reported by dialyzer. Ah, well .. I suspect it was the missing clause in find_terminals and I had it on a TODO somewhere. Should be included to 17.5. // Bj?rn-Egil From andra.dinu@REDACTED Wed Mar 18 12:17:59 2015 From: andra.dinu@REDACTED (Andra Dinu) Date: Wed, 18 Mar 2015 11:17:59 +0000 Subject: [erlang-questions] Erlang User Conference Stockholm 11-12 June - 40 VEB tickets released Message-ID: Hi all, The EUC is back on 11-12 June. This year, besides awesome talks, expect a few changes based on feedback from last year: there will be only 3 tracks/day and talks will be marked with 'beginner', 'intermediate' and 'advanced' tags. Today we released 40 tickets at the Very Early Bird Rate of SEK 3300 (excluding VAT). Grab your ticket, they're going fast! http://www.erlang-factory.com/euc2015 Best, Andra *Andra Dinu* Community & Social Largest Erlang event in the US: Erlang Factory SF Bay Area 26-27 March . Scholarships available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Mar 18 13:53:03 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 18 Mar 2015 13:53:03 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> Message-ID: On Wed, Mar 18, 2015 at 9:28 AM, Ulf Wiger wrote: > I think many of us have been taken aback by this apparent clash of > principles: > The Right to Express your Opinion vs. The Right Not to be Offended. > I had a longish mail that I did not post. It discusses exactly this point, rumaging around John Stuart Mill's work from 1859, "On Liberty". The crux is that freedom of expression[0] doesn't mean you are free to say anything. In particular, you are not allowed to say something which ultimately causes harm to someone else. But you *are* allowed to say things which are deeply offensive to other people, if that is necessary to argue your idea. Universities have a long tradition of following this concept of freedom. In some circumstances, the truth of the matter, the data which has statistical and scientific support, is deeply offensive to the current status quo. Which begs the question of "how university-like do we want the mailing lists to be?". Now, we are lucky in the sense we don't have to directly discuss the harder issues of society very often of this mailing list, but I'm not sure we can claim to be innocent as a group. Some times, we mock other programming language communities (and they mock us, so I guess it is simply fair payback). Some times, we post highly provocative mails that make people rethink their stance on programming (I hope). I'd like to see at least the latter still being a possibility. In addition to Miles and Ulf, I also think Joe has a point by questioning the concept of "being nice". It ties well into the right to express ideas which may be offensive to some. And looking at the current status quo, I don't think we've ever even had an informal "be nice" rule. I have written things, here, where my mind bloody well knows that this may offend someone. But in every case ultimately posted, I've come to the conclusion that it is more important to convey the message than being nice to everybody. Some times a point is contentious, which is a surefure guarantee to offend, *especially* if the evidence is controversial. There are other times, where I've deleted sentences, because their snarky remark did not directly underpin my point, as I believe the right to offend must be used with care and surgical precision. That said, nobody has ever contacted me off-list with anything I've written for which they were offended. Let me throw in another premise, which I'd like to challenge. Challenging this premise may offend somebody, you have been warned :) The premise is that diversity is good for a community. Historically, we've had very little diversity at any level. The price of travel made cultures more static, and were you born into a specific culture, you would usually carry it on. It is only lately, the last 40-60 years, that we've had the possibility of increasing diversity. And *especially* the last 7 years where social networks have created the global village. Yet I think we see relatively little evidence for the gains of diversity in the world, be it historical or recent. A community of odd Erlang programmers are hardly a diverse group. My claim is that this is the norm: most groups aren't diverse, given you look at a certain dimension. It could be age, where COBOL programmers are older, Javascript programmers are younger, and Erlang is perhaps a quite broad mix. It could be gender, where tech is skewed towards men, biochemistry toward women[1], and theology has a 50/50 split. It could be programming language, where MUMPS is programmed by healthcare professionals, or OCaml which definitely enjoys a large following of theoretical computer scientists. I think it is the natural state of affairs. People have always grouped together by finding people with whom they share values. Part of why it is hard to hire COBOL programmers among the young today is the simple fact that the language is seen as obsolete and you don't want to work with 10 old greybearded men[2]. This naturally decreases diversity in groups, because over time "deviants" feel less at home. You can try to counter this by slamming an "inclusivity" label on top, but my personal opinion is that this sticker always has bad glue and falls off, eventually. It has always been my claim, that if you want to get something done, you need to find a small group of likeminded people and get to work. This group needs a certain amount of antidiversity, as it is important certain things is an act of impulse rather than a long-winded meeting. If everyone wants to use git, then git it is. If half want to use subversion, then you have a discussion at hand, slowing down the project. Likemindedness also means that you probably have the same core values as a group. That is, what is valuable to you, are also valuable to your peers. Once the group operates, a healthy dose of new ideas can improve the state of affairs. But the like-mindedness has a sponge-effect such that the new ideas are absorbed slowly over time. In short: no diversity is bad. Some diversity is good. And too much diversity is a clusterfuck. When the latter situation is reached and the clusterfuck is imminent, people leave to form new groups in which there is less diversity but more like-mindedness. You only have to take a quick glance at online social networks to see this effect. [0] Here "freedom of expression" is *not* rooted in the laws of any country, however which way the wording overlap. The 1st amendment only has legislative power in the US, and I'm not an US citizen. What you are allowed to write, say, or yell from a mountain top is parameterized by culture and your local laws. [1] At least taking Danish universities as a base case. [2] I'm fully aware I'm guilty of stereotyping, but have pity on me for using a rhetorical device :) -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Mar 18 13:59:47 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 18 Mar 2015 13:59:47 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: <55083530.2070108@ninenines.eu> <20150317142651.GB11827@ferdair.local> Message-ID: On Tue, Mar 17, 2015 at 10:51 PM, Leandro Ostera wrote: > Fundamental to deterministic builds is not being able to *republish* under > a version name. Which obligues > you to increment your semver with every fix, feature, and major overhaul. > Indeed! Either you ignore the problem entirely, like the Go community is currently doing, or you define a system in which the name of a package is derived from its content. For instance by taking a checksum over a tarball of the source, or something like this. Content-Addressable-Storage is a nice thing because it eliminates the problem with accidentally overwriting history. And furthermore, it guarantees static data which in turn enables free caching of any package at any system. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Mar 18 14:02:20 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 18 Mar 2015 14:02:20 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: <55083530.2070108@ninenines.eu> <20150317142651.GB11827@ferdair.local> <550900DD.3000302@gmail.com> Message-ID: On Wed, Mar 18, 2015 at 10:34 AM, David Welton wrote: > There is probably an argument to be made that using code from people > who push tags and then subsequently fiddle with them is probably a bad > idea in other ways too. > This is the stance taken by the Go community. If you destroy your "master" branch, then people will eventually learn your project is bad and vendor it by forking. Since import-statements contain the repository location, you uniquely identify the version by its location. This solves some problems, but is a phase-shift: it creates other problems, and time will show if they are easier or harder to deal with. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Mar 18 14:21:43 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 18 Mar 2015 14:21:43 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> Message-ID: <55097BE7.5050409@ninenines.eu> On 03/18/2015 01:53 PM, Jesper Louis Andersen wrote: > > On Wed, Mar 18, 2015 at 9:28 AM, Ulf Wiger > wrote: > > I think many of us have been taken aback by this apparent clash of > principles: > The Right to Express your Opinion vs. The Right Not to be Offended. > > > I had a longish mail that I did not post. It discusses exactly this > point, rumaging around John Stuart Mill's work from 1859, "On Liberty". > The crux is that freedom of expression[0] doesn't mean you are free to > say anything. In particular, you are not allowed to say something which > ultimately causes harm to someone else. But you *are* allowed to say > things which are deeply offensive to other people, if that is necessary > to argue your idea. > > Universities have a long tradition of following this concept of freedom. > In some circumstances, the truth of the matter, the data which has > statistical and scientific support, is deeply offensive to the current > status quo. Which begs the question of "how university-like do we want > the mailing lists to be?". Now, we are lucky in the sense we don't have > to directly discuss the harder issues of society very often of this > mailing list, but I'm not sure we can claim to be innocent as a group. > Some times, we mock other programming language communities (and they > mock us, so I guess it is simply fair payback). Some times, we post > highly provocative mails that make people rethink their stance on > programming (I hope). I'd like to see at least the latter still being a > possibility. > > In addition to Miles and Ulf, I also think Joe has a point by > questioning the concept of "being nice". It ties well into the right to > express ideas which may be offensive to some. Be nice to people, not to ideas. To give an example: Good: Javascript sucks because A B C. Bad: You suck because you like Javascript. Better: Erlang has improvements D E F over Javascript which allow you to G H I. Not only will you not convince someone to stop using Javascript if you use the Bad form, but they will most likely ignore you or leave and never come back again. The Good form can still offend some people (inventors of Javascript for example), but most will just shrug it off and move on. The Better form is strictly positive and will most likely not offend anyone. And you get to teach that person good things about Erlang too. Another example: Good: Your idea is bad because A B C. Bad: Your idea is moronic. Better: Your idea could be improved by D E F. / Have you looked at G? Most people I know in the Erlang community use the Better form most of the time, and the Good form on occasion, which is why the CoC feels so unnecessary to me. Though if there had to be a CoC, I would really prefer one that includes what I mention here, as the CoC would encourage people to use the Better form rather than discourage people from using the Bad form. -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Wed Mar 18 14:23:07 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 18 Mar 2015 14:23:07 +0100 Subject: [erlang-questions] A question of style In-Reply-To: References: Message-ID: On Tue, Mar 17, 2015 at 2:55 PM, Joe Armstrong wrote: > The more I think about it the more I come to the conclusion that we > should not be writing polymorphic interfaces to libraries and making > them easy to use. Instead we should be writing minimal libraries > containing only essential features. > This has always been my point of view. Several remarks: * It is by far the solution with the best type-system overlay. Suppose Erlang had a static type system. Then this is essentially the first and simplest solution that comes up if you have static types. The key is how your library composes with other code. And compositionally with "everything" has considerably less structural rigor than "only composable with this or that". * The library becomes much simpler. If you really want, then having a compatibility layer module is probably better in the long run. Convert in the layer and then pass on the data to the real system. Programmers who know the API can call it directly, avoiding the conversion layer. * It is transparent. Code calling binary_to_list/1 internally increases the memory resource pressure by a factor of 20. Hiding this in the library gives you less information. You thought it operated on binary data, but it really operates on strings, internally. This tells you a lot about its resource consumption. For instance that it isn't made to be used with binary data several megabytes in size. * Breaking the assumption crashes the process. This is a good thing! Implicit polymorphic conversion *decides for you*. Sometimes the code makes the right call, and the conversion is exactly like you want. Sometimes, it accepts the wrong data, converts it to something completely random and processes that. It can lead to misery. Library code shouldn't decide for the caller what to do. The caller knows. * A major problem in all software is the question "does my data have the right structure here?" We do lots of conversions all the time. We read a binary() value. We convert it into structural JSON. We grab fields in the JSON structure and interpret them into other internal data values. The purpose of conversion code is to handle this, and it is hard to see how you can get around having to describe the conversion at least somewhere in the program. * Hidden conversions between data and polymorphic acceptance is costly. If your internals are converting back and forth between representations of the same data, you want to know this is the case. Once you compose several polymorphic accepting functions, you pay in execution speed, memory usage through extra GC pressure and lack of precise understanding of data mangling (which misconverts your data). It is evil! * The more generic an API, the less it tends to say. As one who enjoys programming OCaml, the power stemming from a type-level restriction is the precision in the surrounding code context. You know exactly what data you have and thus also exactly what functions can manipulate it. This restriction is a spotlight on API-usage because I can ask "what API calls can satisfy my need?" and not get back "EVERYTHING! BLOODY EVERYTHING!" -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gguthrie@REDACTED Wed Mar 18 14:32:54 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Wed, 18 Mar 2015 13:32:54 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <55097BE7.5050409@ninenines.eu> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: > Most people I know in the Erlang community use the Better form most of the time, and the Good form on occasion, which is why the CoC feels so unnecessary to me. I will repeat what I said previously - you don't write supervisions trees for process that don't crash - and you don't write codes of conduct for flame wars about bloody editors I can't think of a single example from the mailing list which would draw down the CoC - and that's a good thing. I am introducing a CoC for Erlang events because I have become aware of sexual assaults against female engineers at tech events (some of which I have attended). This discussion is all getting a bit self indulgent. Pretending that the context of this CoC is NOT people reading horror stories about tech in their newspapers is all very la-la-la-la I do agree with Gareth when he said the introduction of it has not been handled very well - a Request For Comment first might have been a good idea... Gordon On Wed, Mar 18, 2015 at 1:21 PM, Lo?c Hoguin wrote: > On 03/18/2015 01:53 PM, Jesper Louis Andersen wrote: > >> >> On Wed, Mar 18, 2015 at 9:28 AM, Ulf Wiger > > wrote: >> >> I think many of us have been taken aback by this apparent clash of >> principles: >> The Right to Express your Opinion vs. The Right Not to be Offended. >> >> >> I had a longish mail that I did not post. It discusses exactly this >> point, rumaging around John Stuart Mill's work from 1859, "On Liberty". >> The crux is that freedom of expression[0] doesn't mean you are free to >> say anything. In particular, you are not allowed to say something which >> ultimately causes harm to someone else. But you *are* allowed to say >> things which are deeply offensive to other people, if that is necessary >> to argue your idea. >> >> Universities have a long tradition of following this concept of freedom. >> In some circumstances, the truth of the matter, the data which has >> statistical and scientific support, is deeply offensive to the current >> status quo. Which begs the question of "how university-like do we want >> the mailing lists to be?". Now, we are lucky in the sense we don't have >> to directly discuss the harder issues of society very often of this >> mailing list, but I'm not sure we can claim to be innocent as a group. >> Some times, we mock other programming language communities (and they >> mock us, so I guess it is simply fair payback). Some times, we post >> highly provocative mails that make people rethink their stance on >> programming (I hope). I'd like to see at least the latter still being a >> possibility. >> >> In addition to Miles and Ulf, I also think Joe has a point by >> questioning the concept of "being nice". It ties well into the right to >> express ideas which may be offensive to some. >> > > Be nice to people, not to ideas. > > To give an example: > > Good: Javascript sucks because A B C. > Bad: You suck because you like Javascript. > Better: Erlang has improvements D E F over Javascript which allow you to G > H I. > > Not only will you not convince someone to stop using Javascript if you use > the Bad form, but they will most likely ignore you or leave and never come > back again. > > The Good form can still offend some people (inventors of Javascript for > example), but most will just shrug it off and move on. > > The Better form is strictly positive and will most likely not offend > anyone. And you get to teach that person good things about Erlang too. > > Another example: > > Good: Your idea is bad because A B C. > Bad: Your idea is moronic. > Better: Your idea could be improved by D E F. / Have you looked at G? > > Most people I know in the Erlang community use the Better form most of the > time, and the Good form on occasion, which is why the CoC feels so > unnecessary to me. > > Though if there had to be a CoC, I would really prefer one that includes > what I mention here, as the CoC would encourage people to use the Better > form rather than discourage people from using the Bad form. > > -- > 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 bchesneau@REDACTED Wed Mar 18 14:50:53 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Wed, 18 Mar 2015 14:50:53 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: On Wed, Mar 18, 2015 at 2:32 PM, Gordon Guthrie wrote: > > Most people I know in the Erlang community use the Better form most of > the time, and the Good form on occasion, which is why the CoC feels so > unnecessary to me. > > I will repeat what I said previously - you don't write supervisions trees > for process that don't crash - and you don't write codes of conduct for > flame wars about bloody editors > > I can't think of a single example from the mailing list which would draw > down the CoC - and that's a good thing. > > I am introducing a CoC for Erlang events because I have become aware of > sexual assaults against female engineers at tech events (some of which I > have attended). > Which assaults? In which events? > > This discussion is all getting a bit self indulgent. > > Pretending that the context of this CoC is NOT people reading horror > stories about tech in their newspapers is all very la-la-la-la > Pretending that CoC are solving issue is also very la-la-la-la, very care-bear world in fact. It is only there to enforce rules when it is needed. So after the facts. If there is a CoC anyway then it imply there is a something able to enforce it. Who/what is in charge of enforcing it. It should be clearly defined. How people will be able to defends themselves against the club rules? How do you make this rule enforcement fair for all party to make sure there won't be abuse? How this can be checked? (Note that this is why we elect people to vote rule and another to check their applications in some countries). I didn't see yet a CoC that makes it clear. And this is very disturbing. Also the most disturbing thing in the CoC for me is that it imply a common culture between people. So how do you define the commons? Isn't it yet defined by the laws? About "beeing nice" why should I have to be nice. I would prefer to enforce an honest, polit and respectful behaviour than having someone nice but dishonest. And this shouldn't require a CoC except the one you're already using when you cross the street. - benoit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Mar 18 14:51:58 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 18 Mar 2015 14:51:58 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: <550982FE.7000306@ninenines.eu> On 03/18/2015 02:32 PM, Gordon Guthrie wrote: > > Most people I know in the Erlang community use the Better form most > of the time, and the Good form on occasion, which is why the CoC feels > so unnecessary to me. > > I will repeat what I said previously - you don't write supervisions > trees for process that don't crash - and you don't write codes of > conduct for flame wars about bloody editors > > I can't think of a single example from the mailing list which would draw > down the CoC - and that's a good thing. > > I am introducing a CoC for Erlang events because I have become aware of > sexual assaults against female engineers at tech events (some of which I > have attended). I probably am not the only one here who do not understand why you bring up a CoC for real world events in this discussion. The only power whoever enforces the CoC here has is to ban you from the mailing list/issue tracker. Therefore it can only make rules about user content. So yes it is all about verbal abuse, flame wars and spam. -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Wed Mar 18 15:24:15 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 18 Mar 2015 15:24:15 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: On Wed, Mar 18, 2015 at 2:32 PM, Gordon Guthrie wrote: > I am introducing a CoC for Erlang events because I have become aware of > sexual assaults against female engineers at tech events (some of which I > have attended). While somewhat tangential to this discussion, I think this is the right move for events/conferences. Whenever you have an incident, it will often be against a female engineer because statistics says so. And you better come proactively prepared to handle the incident, so you don't have to begin drawing in information once it happens. It can get pretty heated. I'd argue conference organizers needs to educated about human psychology to handle the situation, as you will risk dealing with the darker parts of the human mind. Law enforcement doesn't get educated in the subject for fun: they deal with heated arguments on a daily basis. As a conference organizer you can't a priori claim to have the same level of education and experience, so I'd suggest that the responsible people make sure they have the necessary knowledge. It is also worth mentioning that culture plays a role. An event where people come from all over the world means the risk of misinterpretation is much higher than normal. Which in turn means that what is taken for a resounding "NO" in one culture might not elicit the same cues in another. Knowing how to defuse such situations before they explode is highly beneficial, and this is where a CoC can level the playing field among several cultures for an event. As for the horror stories in the news, several factors plays a role. News media are vultures for these stories, because they generate ad revenue. A large part also has to do with what I colloquially call "outrage culture" in which relatively small incidents gets blown up to the point where the outrage overtakes the narrative. At this point, due to the amplification factor of social networking, anything can happen, and it usually ends in misery for every party involved. These two factors ensures you can't ever be fully guarded against a horror story, even if you try very hard[0]. [0] Scott Aaronson, the quantum computing complexity theorist, provides an ever so eloquent introduction to online shaming culture http://www.scottaaronson.com/blog/?p=2221 which I heartily recommend. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From e@REDACTED Wed Mar 18 15:27:18 2015 From: e@REDACTED (e@REDACTED) Date: Wed, 18 Mar 2015 15:27:18 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: <55098B46.408@bestmx.net> On 03/18/2015 02:32 PM, Gordon Guthrie wrote: > I am introducing a CoC for Erlang events because I have become aware of > sexual assaults against female engineers at tech events it is called Humiliation By Protection. 'nuff said. From max.lapshin@REDACTED Wed Mar 18 15:34:18 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 18 Mar 2015 17:34:18 +0300 Subject: [erlang-questions] Erlang, dirfy nifs, scheduler threads Message-ID: Hi. Some time ago I've put ffmpeg inside erlang and made transcoding inside erlang. To make it working I had to start thread per each instance of encoder/decoder and make my own thread pool, because R17 could get locked after some time. Now I want to update to R17.4 and use nif flags: {"decode0_nif", 4, avcodec_async_decode, ERL_NIF_DIRTY_JOB_CPU_BOUND}, what is the proper way to understand that erlang got stuck due to bad calculation of nif timing? Maybe I should write to logs some metric periodically? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Mar 18 16:32:52 2015 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 18 Mar 2015 16:32:52 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: I like top posts: Why: 1) People have short span of attention - they only read the first few lines, then decide whether they want to read the rest. I know for a fact that people follow links near the top of my blogs and not near the end - the stuffs so boring they don't get to the end. 2) Interleaving replies with previously posted text often results in a mess where it's impossible to see who said what, especially if their are multiple interleaving. I have recently heard of deliberate manipulation of previously published text, in attempt to manipulate a discussion. Separately posted articles makes it clear who said what and the postings can be digitally signed 3) Top postings aren't really at the top - the subject line in the mail is at the top. 4) The topmost posting is often the most interesting and an indication that a topic is worth of a discussion. -- on niceness etc. Would I want to live in a world where everybody was nice? (this would make an interesting essay topic - there is not sufficient space to answer here :-) My view on this is that there are two types of behavioral standards a) what you were taught as a kid - "share your toys" - "stop hitting Tommy" and what the social norms of your tribe are b) what the laws of the land are - "do not thump people" I don't see what we need something in the middle - bullying, general nastiness to the extent that it is criminal needs no action. Telling adults how to behave at conferences seems very strange to me - Adults should *know* the rules of their tribe and the laws of the land. If they break these spoken or unspoken rules there will be consequences. I read Gordon's mail on this and was horrified that he had come across behavior that would break standards a) and b) - I don't see how writing more rules will change behavior. Laws that are enforced probably do (slowly) change behavior. Nasty people will be nasty and not stop being nasty because of more rules. Their already are rules which they don't obey. On the very odd occasion where I've come across really bad behavior I have taken the people aside and just told them that I do not accept their behavior and told them to off. Tricky subject ... I think just "being nice" doesn't do justice to the problem Lady Hartley's rules did after all take 356 pages. Interestingly about half of the book was a "Manual of Politeness" - Being polite never does any harm. So we should not say "this code is crap" we should say "having perused my learned colleagues code and admired it for its elegance, structure and beauty, I have however found one small element where in my humble opinion it might be slightly improved .." Cheers /Joe On Wed, Mar 18, 2015 at 3:24 PM, Jesper Louis Andersen wrote: > > On Wed, Mar 18, 2015 at 2:32 PM, Gordon Guthrie wrote: >> >> I am introducing a CoC for Erlang events because I have become aware of >> sexual assaults against female engineers at tech events (some of which I >> have attended). > > > While somewhat tangential to this discussion, I think this is the right move > for events/conferences. Whenever you have an incident, it will often be > against a female engineer because statistics says so. And you better come > proactively prepared to handle the incident, so you don't have to begin > drawing in information once it happens. It can get pretty heated. I'd argue > conference organizers needs to educated about human psychology to handle > the situation, as you will risk dealing with the darker parts of the human > mind. Law enforcement doesn't get educated in the subject for fun: they deal > with heated arguments on a daily basis. As a conference organizer you can't > a priori claim to have the same level of education and experience, so I'd > suggest that the responsible people make sure they have the necessary > knowledge. > > It is also worth mentioning that culture plays a role. An event where people > come from all over the world means the risk of misinterpretation is much > higher than normal. Which in turn means that what is taken for a resounding > "NO" in one culture might not elicit the same cues in another. Knowing how > to defuse such situations before they explode is highly beneficial, and this > is where a CoC can level the playing field among several cultures for an > event. > > As for the horror stories in the news, several factors plays a role. News > media are vultures for these stories, because they generate ad revenue. A > large part also has to do with what I colloquially call "outrage culture" in > which relatively small incidents gets blown up to the point where the > outrage overtakes the narrative. At this point, due to the amplification > factor of social networking, anything can happen, and it usually ends in > misery for every party involved. These two factors ensures you can't ever be > fully guarded against a horror story, even if you try very hard[0]. > > [0] Scott Aaronson, the quantum computing complexity theorist, provides an > ever so eloquent introduction to online shaming culture > http://www.scottaaronson.com/blog/?p=2221 which I heartily recommend. > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mahesh@REDACTED Wed Mar 18 16:51:27 2015 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Wed, 18 Mar 2015 16:51:27 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: An interesting about security cameras is that most of them aren't actually wired up to anything (and lets not get into whether anybody is even watching) What a security camera *does* do is give mind pause. If, _just that one time_ your inner devil might tempt you into slipping that $1 bar of chocolate into your pocket, the realization that there is a security camera over there is invariably sufficient to prevent you from doing so. And in most places, that is reason enough to put a security camera in place (and usually, quite visibly too, otherwise what would be the point?) I trust the point is made... Cheers On Wed, Mar 18, 2015 at 4:32 PM, Joe Armstrong wrote: > > I like top posts: > > Why: > > 1) People have short span of attention - they only read the first few > lines, then decide > whether they want to read the rest. I know for a fact that people > follow links near the top of my > blogs and not near the end - the stuffs so boring they don't get to the end. > > 2) Interleaving replies with previously posted text often results in a > mess where it's impossible > to see who said what, especially if their are multiple interleaving. I > have recently heard of > deliberate manipulation of previously published text, in attempt to > manipulate a discussion. > > Separately posted articles makes it clear who said what and the > postings can be digitally signed > > 3) Top postings aren't really at the top - the subject line in the > mail is at the top. > > 4) The topmost posting is often the most interesting and an indication > that a topic is > worth of a discussion. > > -- on niceness etc. > > Would I want to live in a world where everybody was nice? > > (this would make an interesting essay topic - there is not sufficient > space to answer here :-) > > My view on this is that there are two types of behavioral standards > > a) what you were taught as a kid - "share your toys" - "stop hitting Tommy" > and what the social norms of your tribe are > b) what the laws of the land are - "do not thump people" > > I don't see what we need something in the middle - bullying, general > nastiness to the extent > that it is criminal needs no action. > > Telling adults how to behave at conferences seems very strange to me - > Adults should *know* > the rules of their tribe and the laws of the land. If they break these > spoken or unspoken rules > there will be consequences. > > I read Gordon's mail on this and was horrified that he had come across > behavior that > would break standards a) and b) - I don't see how writing more rules > will change behavior. > Laws that are enforced probably do (slowly) change behavior. Nasty > people will be nasty > and not stop being nasty because of more rules. Their already are > rules which they don't obey. > > On the very odd occasion where I've come across really bad behavior I > have taken the people > aside and just told them that I do not accept their behavior and told them to > off. > > Tricky subject ... > > I think just "being nice" doesn't do justice to the problem > > Lady Hartley's rules did after all take 356 pages. > > Interestingly about half of the book was a "Manual of Politeness" - > Being polite never does any harm. > > So we should not say "this code is crap" we should say > > "having perused my learned colleagues code and admired it for its > elegance, structure and beauty, > I have however found one small element where in my humble opinion it > might be slightly improved .." > > Cheers > > /Joe > > > > On Wed, Mar 18, 2015 at 3:24 PM, Jesper Louis Andersen > wrote: > > > > On Wed, Mar 18, 2015 at 2:32 PM, Gordon Guthrie wrote: > >> > >> I am introducing a CoC for Erlang events because I have become aware of > >> sexual assaults against female engineers at tech events (some of which I > >> have attended). > > > > > > While somewhat tangential to this discussion, I think this is the right move > > for events/conferences. Whenever you have an incident, it will often be > > against a female engineer because statistics says so. And you better come > > proactively prepared to handle the incident, so you don't have to begin > > drawing in information once it happens. It can get pretty heated. I'd argue > > conference organizers needs to educated about human psychology to handle > > the situation, as you will risk dealing with the darker parts of the human > > mind. Law enforcement doesn't get educated in the subject for fun: they deal > > with heated arguments on a daily basis. As a conference organizer you can't > > a priori claim to have the same level of education and experience, so I'd > > suggest that the responsible people make sure they have the necessary > > knowledge. > > > > It is also worth mentioning that culture plays a role. An event where people > > come from all over the world means the risk of misinterpretation is much > > higher than normal. Which in turn means that what is taken for a resounding > > "NO" in one culture might not elicit the same cues in another. Knowing how > > to defuse such situations before they explode is highly beneficial, and this > > is where a CoC can level the playing field among several cultures for an > > event. > > > > As for the horror stories in the news, several factors plays a role. News > > media are vultures for these stories, because they generate ad revenue. A > > large part also has to do with what I colloquially call "outrage culture" in > > which relatively small incidents gets blown up to the point where the > > outrage overtakes the narrative. At this point, due to the amplification > > factor of social networking, anything can happen, and it usually ends in > > misery for every party involved. These two factors ensures you can't ever be > > fully guarded against a horror story, even if you try very hard[0]. > > > > [0] Scott Aaronson, the quantum computing complexity theorist, provides an > > ever so eloquent introduction to online shaming culture > > http://www.scottaaronson.com/blog/?p=2221 which I heartily recommend. > > > > -- > > J. > > > > _______________________________________________ > > 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 -- Mahesh Paolini-Subramanya That tall bald Indian guy.. Google+ | Blog | Twitter | LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From e@REDACTED Wed Mar 18 17:10:43 2015 From: e@REDACTED (e@REDACTED) Date: Wed, 18 Mar 2015 17:10:43 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> Message-ID: <5509A383.2010703@bestmx.net> On 03/18/2015 04:32 PM, Joe Armstrong wrote: > I like top posts: > > Why: > > 1) People have short span of attention - they only read the first few > lines, then decide pardon me, do you seriously assume that people have only sequential access to a text? > I know for a fact that people > follow links near the top of my > blogs and not near the end - the stuffs so boring they don't get to the end. very good filter for those who are not interested in a productive conversation > 2) Interleaving replies with previously posted text often results in a > mess where it's impossible cooking often results in a mess. repair often results in a mess. publishing books often results in a mess. programming often results in a mess. > to see who said what, especially if their are multiple interleaving. I > have recently heard of > deliberate manipulation of previously published text, in attempt to > manipulate a discussion. ok, in order to prevent improper quotations let's just omit all quotation at once! good riddance! i also suggest to forbid all tools that might be misused. > Separately posted articles makes it clear who said what leaving totally unclear WHY did they say that. > 3) Top postings aren't really at the top - the subject line in the > mail is at the top. no. "Return-Path:" line is on the top. > 4) The topmost posting is often the most interesting and an indication > that a topic is worth of a discussion. it is so incomprehensible and ridiculous claim that i just decided to quote it as is. From heinz@REDACTED Wed Mar 18 18:09:22 2015 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Wed, 18 Mar 2015 18:09:22 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5509A383.2010703@bestmx.net> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> Message-ID: I honestly think, the place where you post a reply, or how long your lines are have no place in a Code of Conduct. It has nothing to do with how you conduct yourself, there will always be people who prefer one over the other and most modern mail client take care of formatting it to the way you like (wrapping lines at the window width, collapsing nested quotes etc.) If anything rules like that seem to go against the idea of being inclusive. The only reason I can think of including those kinds of rules into a code of conduct would be impact on screen readers for people with eyesight problems, however I have no idea how it affects them it would however be interesting of hearing from someone with experience of that. --- Cheers, Heinz Nikolaus Gies heinz@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From erlang@REDACTED Wed Mar 18 18:51:17 2015 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 18 Mar 2015 18:51:17 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: <55083530.2070108@ninenines.eu> References: <55083530.2070108@ninenines.eu> Message-ID: On Tue, Mar 17, 2015 at 3:07 PM, Lo?c Hoguin wrote: > On 03/17/2015 02:53 PM, Joe Armstrong wrote: >> >> How do I include another application in my application? >> >> I've written a program that I want to distibute. >> I'll make it available on github. >> >> The problem is that my program uses cowboy and a few other >> things (which are also on github) >> >> I'd like my program to work "out of the box" - just type Make and off >> you go. >> >> I'd also like my to work for a long time so if rebar and >> cowboy change in the future I'd like my program to still build >> correctly. >> >> Now what I could do is: >> >> use rebar and a rebar.config file that point to cowboy etc. >> >> My rebar-config is like this >> >> {deps, [ >> ... >> {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}} >> ]}. >> >> The problem with this is that >> >> 1) my version of rebar might not be the same as on the target machine >> where the makefile is run > > > This is a problem erlang.mk solves. You include erlang.mk in your project > therefore everyone has the same when they compile it. > > You still are at the whim of Make having an incompatible change that breaks > something, but you also have that issue with rebar when a newer Erlang > version breaks something in it. The chances of either happening are very > slim though. > >> 2) The cowboy reference is to "the latest version" and not >> an immutable version that I know works >> >> So How should I fix this? Is the answer: >> >> a) Include rebar in my distribution >> (I don't really like this, since I'd just like to have my code in >> my project archive) > > > That's what I would advise you to do, though. Do note however that if your > project is to be used as a dependency then it won't be your rebar that will > be used but the user's (or the top-level project's) rebar. > > This is another issue erlang.mk solves as the dependency's Makefile is > always used and not the top-level erlang.mk. The dependency can run a > different erlang.mk or just a plain Makefile, or even a Makefile that calls > the bundled rebar, it doesn't matter as long as there is a Makefile. > >> b) Point to a absolute version of cowboy - but how do I do this? > > > Simply put the tag or commit number instead of "master" in rebar.config, for > example "1.0.1". > > Make sure to do this with all your dependencies, and check that the > dependencies themselves do it. I've run into another problem - Right now I have a working program that I want to make sure works on other peoples machines. So they need to get exactly the version I have Right now I clone cowboy cowlib and ranch I then checkout master from cowboy tag 1.2.0 from cowlib tag 1.0.0 from ranch Everything works fine - great If I publish this I assume the tagged versions 1.2.0 1.0.0 or cowlib and ranch will be the same - but in the future master won't be the same I then did a (inside cowboy) > git checkout master and then > git describe fatal: No annotated tags can describe '90ae31998e8d0887b9efe4b441136ac047708bb9'. >From which I assume that I can use 90ae... etc as an immutable reference to cowboy, and the 1.2.0 1.0.0 tags for cowlib and ranch So now what I have to do is clone cowboy and checkout 90ae31998e8d0887b9efe4b441136ac047708bb9'. clone cowlib and checkout 1.2.0 clone ranch and checkout 1.0.0 Anybody who does this should get the same code as I have on my machine is this correct? Can I trust the tags? - do I have to converts these to shas with git describe as well? Cheers /Joe > > I believe rebar3 has a way to lock dependencies into a specific commit for > the projects that depend on another's "master". > >> Or c) >> Include all the source code of cowboy etc in my release > > > This also works but will prove to be more time consuming when you need to > update dependencies. However if you intend to just release the project and > make little maintenance over it afterward (for example if it's a proof of > concept or a prototype) then this might just be the way to go. > > -- > Lo?c Hoguin > http://ninenines.eu From felixgallo@REDACTED Wed Mar 18 19:09:57 2015 From: felixgallo@REDACTED (Felix Gallo) Date: Wed, 18 Mar 2015 11:09:57 -0700 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: <55083530.2070108@ninenines.eu> Message-ID: I think you can probably trust Lo?c to do the right thing and never point those tags at different commits. So for that code, tag is probably fine. Generally I find myself pointing at commits, though; not that much more effort, and provides a solid invariant. For code that absolutely has to work (manages $10B or more in assets under management, runs MRI machines, etc.), I fork the project on github and point my project at my fork. That way even if the base repo dies or, worse, suffers some kind of malevolent attack, the dependency is safe as long as github itself is safe. You can fork infinitely on github. Over $500B assets under management, I run my own repo... F. On Wed, Mar 18, 2015 at 10:51 AM, Joe Armstrong wrote: > On Tue, Mar 17, 2015 at 3:07 PM, Lo?c Hoguin wrote: > > On 03/17/2015 02:53 PM, Joe Armstrong wrote: > >> > >> How do I include another application in my application? > >> > >> I've written a program that I want to distibute. > >> I'll make it available on github. > >> > >> The problem is that my program uses cowboy and a few other > >> things (which are also on github) > >> > >> I'd like my program to work "out of the box" - just type Make and off > >> you go. > >> > >> I'd also like my to work for a long time so if rebar and > >> cowboy change in the future I'd like my program to still build > >> correctly. > >> > >> Now what I could do is: > >> > >> use rebar and a rebar.config file that point to cowboy etc. > >> > >> My rebar-config is like this > >> > >> {deps, [ > >> ... > >> {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", > "master"}} > >> ]}. > >> > >> The problem with this is that > >> > >> 1) my version of rebar might not be the same as on the target > machine > >> where the makefile is run > > > > > > This is a problem erlang.mk solves. You include erlang.mk in your > project > > therefore everyone has the same when they compile it. > > > > You still are at the whim of Make having an incompatible change that > breaks > > something, but you also have that issue with rebar when a newer Erlang > > version breaks something in it. The chances of either happening are very > > slim though. > > > >> 2) The cowboy reference is to "the latest version" and not > >> an immutable version that I know works > >> > >> So How should I fix this? Is the answer: > >> > >> a) Include rebar in my distribution > >> (I don't really like this, since I'd just like to have my code in > >> my project archive) > > > > > > That's what I would advise you to do, though. Do note however that if > your > > project is to be used as a dependency then it won't be your rebar that > will > > be used but the user's (or the top-level project's) rebar. > > > > This is another issue erlang.mk solves as the dependency's Makefile is > > always used and not the top-level erlang.mk. The dependency can run a > > different erlang.mk or just a plain Makefile, or even a Makefile that > calls > > the bundled rebar, it doesn't matter as long as there is a Makefile. > > > >> b) Point to a absolute version of cowboy - but how do I do this? > > > > > > Simply put the tag or commit number instead of "master" in rebar.config, > for > > example "1.0.1". > > > > Make sure to do this with all your dependencies, and check that the > > dependencies themselves do it. > > I've run into another problem - > Right now I have a working program that I want to make sure works on > other peoples machines. So they need to get exactly the version I have > > Right now I clone cowboy cowlib and ranch > > I then checkout master from cowboy > tag 1.2.0 from cowlib > tag 1.0.0 from ranch > > Everything works fine - great > > If I publish this I assume the tagged versions 1.2.0 1.0.0 or cowlib and > ranch > will be the same - but in the future master won't be the same > > I then did a (inside cowboy) > > > git checkout master > > and then > > > git describe > > fatal: No annotated tags can describe > '90ae31998e8d0887b9efe4b441136ac047708bb9'. > > From which I assume that I can use 90ae... etc as an immutable reference to > cowboy, and the 1.2.0 1.0.0 tags for cowlib and ranch > > So now what I have to do is > > clone cowboy and checkout 90ae31998e8d0887b9efe4b441136ac047708bb9'. > clone cowlib and checkout 1.2.0 > clone ranch and checkout 1.0.0 > > Anybody who does this should get the same code as I have on my machine > is this correct? > > Can I trust the tags? - do I have to converts these to shas with git > describe > as well? > > Cheers > > /Joe > > > > > > > > > I believe rebar3 has a way to lock dependencies into a specific commit > for > > the projects that depend on another's "master". > > > >> Or c) > >> Include all the source code of cowboy etc in my release > > > > > > This also works but will prove to be more time consuming when you need to > > update dependencies. However if you intend to just release the project > and > > make little maintenance over it afterward (for example if it's a proof of > > concept or a prototype) then this might just be the way to go. > > > > -- > > 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 essen@REDACTED Wed Mar 18 19:20:31 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 18 Mar 2015 19:20:31 +0100 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: References: <55083530.2070108@ninenines.eu> Message-ID: <5509C1EF.8050900@ninenines.eu> On 03/18/2015 06:51 PM, Joe Armstrong wrote: > I've run into another problem - > Right now I have a working program that I want to make sure works on > other peoples machines. So they need to get exactly the version I have > > Right now I clone cowboy cowlib and ranch > > I then checkout master from cowboy > tag 1.2.0 from cowlib > tag 1.0.0 from ranch > > Everything works fine - great > > If I publish this I assume the tagged versions 1.2.0 1.0.0 or cowlib and ranch > will be the same - but in the future master won't be the same > > I then did a (inside cowboy) > > > git checkout master > > and then > >> git describe > > fatal: No annotated tags can describe > '90ae31998e8d0887b9efe4b441136ac047708bb9'. > > From which I assume that I can use 90ae... etc as an immutable reference to > cowboy, and the 1.2.0 1.0.0 tags for cowlib and ranch > > So now what I have to do is > > clone cowboy and checkout 90ae31998e8d0887b9efe4b441136ac047708bb9'. > clone cowlib and checkout 1.2.0 > clone ranch and checkout 1.0.0 > > Anybody who does this should get the same code as I have on my machine > is this correct? This is correct. > Can I trust the tags? - do I have to converts these to shas with git describe > as well? You might want to use 'git show --shortstat' instead, describe gives you a different kind of information. Don't trust tags. Even mine. While I do not make a habit of changing history, there are some things that could make force me to, like legal requests. You know where you stand with a sha, it's either there with the source just like it's supposed to be, or it's not there at all. -- Lo?c Hoguin http://ninenines.eu From mononcqc@REDACTED Wed Mar 18 19:24:51 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 18 Mar 2015 14:24:51 -0400 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: <550900DD.3000302@gmail.com> References: <55083530.2070108@ninenines.eu> <20150317142651.GB11827@ferdair.local> <550900DD.3000302@gmail.com> Message-ID: <20150318182450.GF11827@ferdair.local> On 03/17, Kenneth Lakin wrote: > IMHO, someone who's *actually* interested in deterministic builds should > use the immutable info provided by their SCM (revision # for SVN, commit > hash for git, etc.) rather than something that can be changed at any > time. I would be surprised if 'rebar3 lock' didn't convert references to > tags into references to commit hashes. > This is correct. Rebar3 automatically converts tags or branch names to commit numbers and references, and stores these in the rebar.lock file automatically. You can only drive a dependency forward on its tag or branch by invoking `rebar3 upgrade` (for all top-level deps) or `rebar3 upgrade ` (for a specific top-level dep). From e@REDACTED Wed Mar 18 19:36:00 2015 From: e@REDACTED (e@REDACTED) Date: Wed, 18 Mar 2015 19:36:00 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> Message-ID: <5509C590.5010403@bestmx.net> On 03/18/2015 06:09 PM, Heinz Nikolaus Gies wrote: > I honestly think, > the place where you post a reply, or how long your lines are have no place in a Code of Conduct. I honestly think, it is the only topic that deserves to be in CoC, everything else is pretty obvious. > there will always be people who prefer one over the other and most modern mail client take care of formatting this is exactly why it should be explicitly stated. From vincent.dephily@REDACTED Wed Mar 18 19:43:41 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Wed, 18 Mar 2015 19:43:41 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <18081302.eI0vuKfqsD@moltowork> TL;DR: On a mailing list, if you're not quoting inline, it's better to not quote at all. Include only your own text instead of top-posting. On Wednesday 18 March 2015 16:32:52 Joe Armstrong wrote: > I like top posts: > > Why: > > 1) People have short span of attention - they only read the first few > lines, then decide whether they want to read the rest. I know for a fact > that people follow links near the top of my blogs and not near the end - the > stuffs so boring they don't get to the end. [...] > 4) The topmost posting is often the most interesting and an indication > that a topic is worth of a discussion. By that reasoning, nobody is going to read the quote at the bottom, so you might as well leave it. This is not a rhetoric suggestion, but real advice. Including the whole previous text as a block after your own doesn't provide any advantage anyway, that's what archives are here for. It's actually detrimental, because some people (me included) will waste time sifting through the whole blob to see if some of it was used as a quote for further discussion as opposed to just copy-pasted whole. Gmail's long-standing html quoting bug (the first line of the new text begins with '>') make things even more fun. > 2) Interleaving replies with previously posted text often results in a > mess where it's impossible to see who said what, especially if their are > multiple interleaving. I have recently heard of deliberate manipulation of > previously published text, in attempt to manipulate a discussion. The whole purpose of "proper quoting" is to make the discussion clearer. If you end up writing/quoting a tangled mess you've failed at that task and it wasn't proper quoting. Good quoting sometimes require reflowing text inside the quotes to make it readable (just as I did here; a good mailer helps). The alternative you suggest, writing at the top and copy-pasting the whole previous thread below, doesn't help readability at all. > Separately posted articles makes it clear who said what and the > postings can be digitally signed This is a mailling list with archives, if you want to check who said what, check the archives instead of trying to parse the tangled mess of 20 replies that included the whole original message at the bottom. -- Vincent de Phily From drormein@REDACTED Wed Mar 18 20:38:14 2015 From: drormein@REDACTED (Dror Mein) Date: Wed, 18 Mar 2015 19:38:14 +0000 (UTC) Subject: [erlang-questions] garbage collection Message-ID: <1638108699.1116020.1426707494792.JavaMail.yahoo@mail.yahoo.com> So it comes a time that one needs to stop avoiding this issue. I have a process which receives lots and lots of binaries. He is the main culprit when checking his memory (goes up to 7GBytes and more). The eheap memory is 99% allocated to him. It is a registered gen_server. Started toying with recon and this process has too many refc binaries, and he is the recon:bin_leak winner. Obviously, this is bad architecture.? But since I'm looking for a quick fix, I cannot change the sending process. So my plan is to reduce my gen_server to one that only receives a message, and immediately bangs it to a process group to handle all data processing.? Now the question of garbage collection:Does a gen_server garbage collect when he returns from a call/cast/handle_info? Is it better to order him to erlang:garbage_collect after each call/cast/handle_info?Do I do it periodically? Can a process be so busy it never garbage_collects on his own?Should I kill the pg servers periodically to achieve some sort of forced garbage_collection? PS: Is there any process group module that allows you to send a message to the name of the process group and a random member handles the message? because that sounds very useful -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanjo@REDACTED Wed Mar 18 21:27:44 2015 From: juanjo@REDACTED (Juan Jose Comellas) Date: Wed, 18 Mar 2015 17:27:44 -0300 Subject: [erlang-questions] Including other peoples code in my code in a future proof way In-Reply-To: <5509C1EF.8050900@ninenines.eu> References: <55083530.2070108@ninenines.eu> <5509C1EF.8050900@ninenines.eu> Message-ID: I've been using Seth Falcon's rebar_lock_deps_plugin for a while now to track all my commits by revision ID just for this purpose. It was the only way to keep my sanity when building releases on different environments. Otherwise I would have been forced to manually check each dependency before building a release (I did this for a while and I don't recommend it). rebar (< 3.x) will fail when updating transitive dependencies if there are even trivial differences when specifying the repository's URL or version (e.g. git:// and https:// as URL protocols used to reference the same repository in two different packages). On Wed, Mar 18, 2015 at 3:20 PM, Lo?c Hoguin wrote: > On 03/18/2015 06:51 PM, Joe Armstrong wrote: > >> I've run into another problem - >> Right now I have a working program that I want to make sure works on >> other peoples machines. So they need to get exactly the version I have >> >> Right now I clone cowboy cowlib and ranch >> >> I then checkout master from cowboy >> tag 1.2.0 from cowlib >> tag 1.0.0 from ranch >> >> Everything works fine - great >> >> If I publish this I assume the tagged versions 1.2.0 1.0.0 or cowlib and >> ranch >> will be the same - but in the future master won't be the same >> >> I then did a (inside cowboy) >> >> > git checkout master >> >> and then >> >> git describe >>> >> >> fatal: No annotated tags can describe >> '90ae31998e8d0887b9efe4b441136ac047708bb9'. >> >> From which I assume that I can use 90ae... etc as an immutable reference >> to >> cowboy, and the 1.2.0 1.0.0 tags for cowlib and ranch >> >> So now what I have to do is >> >> clone cowboy and checkout 90ae31998e8d0887b9efe4b441136ac047708bb9'. >> clone cowlib and checkout 1.2.0 >> clone ranch and checkout 1.0.0 >> >> Anybody who does this should get the same code as I have on my machine >> is this correct? >> > > This is correct. > > Can I trust the tags? - do I have to converts these to shas with git >> describe >> as well? >> > > You might want to use 'git show --shortstat' instead, describe gives you a > different kind of information. > > Don't trust tags. Even mine. While I do not make a habit of changing > history, there are some things that could make force me to, like legal > requests. You know where you stand with a sha, it's either there with the > source just like it's supposed to be, or it's not there at all. > > > -- > 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 n.oxyde@REDACTED Wed Mar 18 21:40:17 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 18 Mar 2015 21:40:17 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> Message-ID: Le 17 mars 2015 ? 00:27, Richard A. O'Keefe a ?crit : > 5. "Try to break your lines" > > [I would very much like to see people do this. > Once again, however, we have a technical term > "to break a line" that the people who misbehave > probably do not know. Why not simply say > "Keep your lines short. Use the RETURN key to > end each line; do not assume that your readers > will see your text wrapped the way you see it." I disagree. To me your messages look funny (lines *too* short) on my main computer, and just plain unreadable on any mobile screen, because it must wrap it furthermore to make it fit the screen. I don't expect the Web to be hand-wrapped, nor books, nor papers done with LaTeX. Could we finally evolve from plain plain/text to format=flowed plain/text? http://joeclark.org/ffaq.html Regards. From ok@REDACTED Thu Mar 19 01:43:04 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 19 Mar 2015 13:43:04 +1300 Subject: [erlang-questions] A question of style In-Reply-To: References: Message-ID: <04B31AC2-06C9-4C05-99DB-A637F5FDF004@cs.otago.ac.nz> On 18/03/2015, at 2:55 am, Joe Armstrong wrote: > The other day I was writing a program that called some library code > that I had written. > > The library had a routine that could parse a string: > > -module(my_lib). > -export([parse_string/1]). > ... > > In the code I was writing I had a binary B containing a string that I > wanted parsing. For one thing, it's always possible to have two modules: -module(my_lib_core). -export(... only the things that *have* to be exported ...). -module(my_lib). -export(... everything from my_lib_core ...) -export(... a whole bunch of convenience functions ...). A module should encapsulate something, hide some information. If it is impossible or very difficult to implement some function without access to that information, then that function, or something to support it, belongs in the module. Also if putting the function (or support element) inside the module will make a practically important difference to space or time costs, consider putting it in the module. Otherwise, if something *can* stay outside the core module, it *should* stay outside the core. One important exception is if you decide to change the interface. If you found that parse_binary/1 was needed more often than parse_string/1, you might make that the core function, in which case the old function ought to move out, but you might leave it in for a release or two to support old clients. Doing this keeps the core simpler, easier to test, and easier to document. It also makes the core *easier to use*, in the sense that someone who wants to use it has less to learn and fewer mistakes to make. In the case of string -vs- binary, the conversion *can* be done outside the module, and it's not likely to make any difference to performance putting it outside. > So is this true: > > easy to use the library == not easy to understand the library code It depends on what you mean by "easy to use". If you mean "does not require writing much if any glue code", possibly. If you mean "easy to write code that uses the library correctly", maybe not. In the specific case of text, you are *never* going to handle all the ways people might want to represent text. Taking a Smalltalk perspective here, if there is a parsing function, I would like to be able to give it - a string - a stretchy string (think StringBuffer) - a decoded byte array - an external file - ... and the best way to do that is to provide a *stream* of characters. Something that accepts that is "easy to understand" (only one interface method) and "easy to use". I can use the *same* technique to convert a character source to a stream no matter which parser I'm giving it to: JSON parse: aString readStream XML parse: anotherString readStream (FileStream read: 'foo.json') bindOwn: [:s | JSON parse: s] (FileStream read: 'bar.xml' ) bindOwn: [:s | XML parse: s] It's actually *better* than having a lot of so-called convenience methods, because each thing that accepts a stream can be combined with *any* way of making a character stream. So I suggest a paradox: a "lean" module may be *easier* to use than a "rich" module with a lot of special cases. Hmm. Excuse me while I go and rewrite a module or two... From ok@REDACTED Thu Mar 19 02:23:30 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 19 Mar 2015 14:23:30 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> Message-ID: <7ACF549C-E479-4BA4-99DA-B22AFDBDE2C8@cs.otago.ac.nz> I said I agreed with trying to keep lines short. On 19/03/2015, at 9:40 am, Anthony Ramine wrote: > I disagree. To me your messages look funny (lines *too* short) on my main computer, and just plain unreadable on any mobile screen, because it must wrap it furthermore to make it fit the screen. Well, I found your message uncomfortable to read because of its long lines. The point of my message was to *increase* authorial freedom compared with the proposed CoC rule. Instead of saying "74 character limit OR ELSE", I was suggesting "use some judgement". > I don't expect the Web to be hand-wrapped, nor books, nor papers done with LaTeX. The wrapping of books cannot be changed. The wrapping of papers done with LaTeX is *mostly* done by LaTeX, but it is very common for people to have to rewrite text to get good line breaks, even with (La)TeX. One thing any experienced TeXnician is aware of is that text written for one paper size will *not* look good when reformatted for a different size, *when formatted by (La)TeX*. Especially tables. Oddly enough, e-mail is NOT the Web, NOT a book, and NOT a paper done with LaTeX (or Weird, or Lout, or Troff). Anyone who finds my lines too short must have terrible trouble with cereal boxes and newspapers. (And I do know that e-mail isn't either of those. Although it *is* very very much like the letters to the Editor, which conventionally uses much shorter lines than I do.) > Could we finally evolve from plain plain/text to format=flowed plain/text? > > http://joeclark.org/ffaq.html That's pretty much what the Mail program does _anyway_. Basically, all format=flowed does is to take away the author's freedom to use short lines; apart from that it doesn't seem to change anything. The point about mobiles is well taken. I know I had great trouble trying to read e-mail on an iPad using a web mail interface. Mind you, that was because of long lines, not short ones. But you know, there is nothing that stops a mobile phone mail reader from re-breaking paragraphs. From bengt.kleberg@REDACTED Thu Mar 19 07:35:30 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 19 Mar 2015 07:35:30 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <18081302.eI0vuKfqsD@moltowork> References: <18081302.eI0vuKfqsD@moltowork> Message-ID: <550A6E32.6080306@ericsson.com> Greetings, A top post with all the previous content below can save me time. It acts like a cache. I do not have to locate the right email in the archive if I want to check something. It does waste space in aforementioned archive. So perhaps we could change the CoC on quoting to be: Do not quote, to save space in the archive. Quoting inline has been misused to my detriment. I find that the concept brings back unhappy memories and avoid looking at it. bengt On 03/18/2015 07:43 PM, Vincent de Phily wrote: > TL;DR: On a mailing list, if you're not quoting inline, it's better to not > quote at all. Include only your own text instead of top-posting. > > > On Wednesday 18 March 2015 16:32:52 Joe Armstrong wrote: >> I like top posts: >> >> Why: >> >> 1) People have short span of attention - they only read the first few >> lines, then decide whether they want to read the rest. I know for a fact >> that people follow links near the top of my blogs and not near the end - the >> stuffs so boring they don't get to the end. > [...] >> 4) The topmost posting is often the most interesting and an indication >> that a topic is worth of a discussion. > By that reasoning, nobody is going to read the quote at the bottom, so you > might as well leave it. This is not a rhetoric suggestion, but real advice. > Including the whole previous text as a block after your own doesn't provide > any advantage anyway, that's what archives are here for. > > It's actually detrimental, because some people (me included) will waste time > sifting through the whole blob to see if some of it was used as a quote for > further discussion as opposed to just copy-pasted whole. Gmail's long-standing > html quoting bug (the first line of the new text begins with '>') make things > even more fun. > > >> 2) Interleaving replies with previously posted text often results in a >> mess where it's impossible to see who said what, especially if their are >> multiple interleaving. I have recently heard of deliberate manipulation of >> previously published text, in attempt to manipulate a discussion. > The whole purpose of "proper quoting" is to make the discussion clearer. If > you end up writing/quoting a tangled mess you've failed at that task and it > wasn't proper quoting. Good quoting sometimes require reflowing text inside > the quotes to make it readable (just as I did here; a good mailer helps). > > The alternative you suggest, writing at the top and copy-pasting the whole > previous thread below, doesn't help readability at all. > > >> Separately posted articles makes it clear who said what and the >> postings can be digitally signed > This is a mailling list with archives, if you want to check who said what, > check the archives instead of trying to parse the tangled mess of 20 replies > that included the whole original message at the bottom. > > > From bengt.kleberg@REDACTED Thu Mar 19 07:58:22 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 19 Mar 2015 07:58:22 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5509A383.2010703@bestmx.net> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> Message-ID: <550A738E.704@ericsson.com> Greetings, When advocating top posts as better than inline quotes, one reason mentioned is that it is possible to use inline quotes to manipulate the discussion whereas a top post will keep all quotes un-edited below. Sounds logical. The retort to this argument is that to prevent improper quotations no quotes should be allowed. I can not make the leap from, if keeping all text is better than editing it, then the really large edit of removing all text is even better. Someone care to explain the steps? bengt On 03/18/2015 05:10 PM, e@REDACTED wrote: > On 03/18/2015 04:32 PM, Joe Armstrong wrote: >> I like top posts: >> >> Why: >> >> 1) People have short span of attention - they only read the first few >> lines, then decide > > pardon me, > do you seriously assume that people have only sequential access to a > text? > > >> I know for a fact that people >> follow links near the top of my >> blogs and not near the end - the stuffs so boring they don't get to >> the end. > > very good filter for those who are not interested in a productive > conversation > > >> 2) Interleaving replies with previously posted text often results in a >> mess where it's impossible > > cooking often results in a mess. > repair often results in a mess. > publishing books often results in a mess. > programming often results in a mess. > > >> to see who said what, especially if their are multiple interleaving. I >> have recently heard of >> deliberate manipulation of previously published text, in attempt to >> manipulate a discussion. > > ok, > in order to prevent improper quotations let's just omit all quotation > at once! > good riddance! > i also suggest to forbid all tools that might be misused. > > >> Separately posted articles makes it clear who said what > > leaving totally unclear WHY did they say that. > > >> 3) Top postings aren't really at the top - the subject line in the >> mail is at the top. > > no. > "Return-Path:" line is on the top. > > >> 4) The topmost posting is often the most interesting and an indication >> that a topic is worth of a discussion. > > it is so incomprehensible and ridiculous claim that i just decided to > quote it as is. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From e@REDACTED Thu Mar 19 08:40:31 2015 From: e@REDACTED (e@REDACTED) Date: Thu, 19 Mar 2015 08:40:31 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550A6E32.6080306@ericsson.com> References: <18081302.eI0vuKfqsD@moltowork> <550A6E32.6080306@ericsson.com> Message-ID: <550A7D6F.9060302@bestmx.net> On 03/19/2015 07:35 AM, Bengt Kleberg wrote: > A top post with all the previous content below can save me time. i kindly ask all proponents of top-posting to write me one simple distinctive letter with the subject: "i am pro top-posting" i am looking forward to tune up my sieve. From drormein@REDACTED Thu Mar 19 11:05:11 2015 From: drormein@REDACTED (Dror Mein) Date: Thu, 19 Mar 2015 10:05:11 +0000 (UTC) Subject: [erlang-questions] ei_rpc cast Message-ID: <1348794563.500868.1426759511224.JavaMail.yahoo@mail.yahoo.com> I have a cnode sending messages to an erlang mode. Is there a way to perform ei_rpc cast? Can I perform ei_rpc_to and ignore/avoid the ei_rpc_from? perhaps putting zero in the timeout? Can it be done consistently without problems? -------------- next part -------------- An HTML attachment was scrubbed... URL: From v@REDACTED Thu Mar 19 11:51:02 2015 From: v@REDACTED (Valentin Micic) Date: Thu, 19 Mar 2015 12:51:02 +0200 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550A738E.704@ericsson.com> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> Message-ID: Once I was a member of a mailing list that had a very rigid rule formulated in order to save archiving space.: "quotations must not exceed 50% of the new message". The unintended consequence of this approach was that people had to write more if they wanted to ensure that quote is given a fair chance of standing by itself; or they have to quote less, which promoted off-the-topic follow ups (a.k.a. discussion manipulation). Judging from my behavior on that list, I would have to conclude that people did read less of what was written (but they sure did manage to save some archive space). Personally, I am in favor of include everything, but with a few considerations: - Always top-post, and always include complete correspondence up to that time. - If you want to quote something, extract it from the original (included) text (which will remain intact) and place it as a part of your top-post in order to provide a "closer" reference for your comment. The include everything thus formulated could be regarded as a close relative to include nothing approach due to the following: Let's presume that include noting approach, by definition, contains a top-post entry only. Also, presume that in order to comment on a given point, such a point will be extracted from the previous mail and made part of the top-post (therefore, not using in-line commenting method). Then, if one is interested in a HEAD (that is, top-post), it wouldn't matter if the TAIL is empty or non-empty list. In other words. assuming that NEW_POST may take a form of: NEW_POST = [TOP_POST] or NEW_POST = [TOP_POST|PREVIOUS_POSTS] Then, archive maintenance may be as simple as: [TOP_POST|_] = NEW_POST, [TOP_POST|ARCHIVE] V/ On 19 Mar 2015, at 8:58 AM, Bengt Kleberg wrote: > Greetings, > > When advocating top posts as better than inline quotes, one reason mentioned is that it is possible to use inline quotes to manipulate the discussion whereas a top post will keep all quotes un-edited below. Sounds logical. > The retort to this argument is that to prevent improper quotations no quotes should be allowed. > I can not make the leap from, if keeping all text is better than editing it, then the really large edit of removing all text is even better. > > Someone care to explain the steps? > > > bengt > > On 03/18/2015 05:10 PM, e@REDACTED wrote: >> On 03/18/2015 04:32 PM, Joe Armstrong wrote: >>> I like top posts: >>> >>> Why: >>> >>> 1) People have short span of attention - they only read the first few >>> lines, then decide >> >> pardon me, >> do you seriously assume that people have only sequential access to a text? >> >> >>> I know for a fact that people >>> follow links near the top of my >>> blogs and not near the end - the stuffs so boring they don't get to the end. >> >> very good filter for those who are not interested in a productive conversation >> >> >>> 2) Interleaving replies with previously posted text often results in a >>> mess where it's impossible >> >> cooking often results in a mess. >> repair often results in a mess. >> publishing books often results in a mess. >> programming often results in a mess. >> >> >>> to see who said what, especially if their are multiple interleaving. I >>> have recently heard of >>> deliberate manipulation of previously published text, in attempt to >>> manipulate a discussion. >> >> ok, >> in order to prevent improper quotations let's just omit all quotation at once! >> good riddance! >> i also suggest to forbid all tools that might be misused. >> >> >>> Separately posted articles makes it clear who said what >> >> leaving totally unclear WHY did they say that. >> >> >>> 3) Top postings aren't really at the top - the subject line in the >>> mail is at the top. >> >> no. >> "Return-Path:" line is on the top. >> >> >>> 4) The topmost posting is often the most interesting and an indication >>> that a topic is worth of a discussion. >> >> it is so incomprehensible and ridiculous claim that i just decided to quote it as is. >> >> >> _______________________________________________ >> 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 peterhickman386@REDACTED Thu Mar 19 12:30:32 2015 From: peterhickman386@REDACTED (Peter Hickman) Date: Thu, 19 Mar 2015 11:30:32 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> Message-ID: In an attempt to kill the 74 line length nonsense I give you a bunch of lines that are all 74 characters long. I have ordered the lines by length :) In relative terms the longest line, the 'W's is four times longer than the shortest, the 'l's. If course if you are one of those very few people that only use mutt or only use monospaced fonts to read their mail the lines will look all the same. In which case a the 74 character limit might seem reasonable. If the lines do not seem to be to be descending in length then you are probably using a different font than me (something else to reflect on). Is it the Erlang communities way of being "welcoming and inclusive" to ram this down everyones throat for the sake of someone who wants to read everything in mutt? ?make a midden of the world?s garden for the sake of someone who cannot abide the smell of roses? -- C S Lewis, The great divorce. WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Mar 19 14:22:29 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 19 Mar 2015 14:22:29 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <7ACF549C-E479-4BA4-99DA-B22AFDBDE2C8@cs.otago.ac.nz> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <7ACF549C-E479-4BA4-99DA-B22AFDBDE2C8@cs.otago.ac.nz> Message-ID: <7D5D3F9F-A7CF-4DE2-998C-6FA70DF52FD4@gmail.com> Le 19 mars 2015 ? 02:23, Richard A. O'Keefe a ?crit : > I said I agreed with trying to keep lines short. And that's where I disagree. > On 19/03/2015, at 9:40 am, Anthony Ramine wrote: >> I disagree. To me your messages look funny (lines *too* short) on my main computer, and just plain unreadable on any mobile screen, because it must wrap it furthermore to make it fit the screen. > > Well, I found your message uncomfortable to read > because of its long lines. Why is your window so large that my message is uncomfortable? Why waste the screen estate if you want it to show short lines? Want short lines? Have a narrow window. > The point of my message was to *increase* authorial > freedom compared with the proposed CoC rule. > Instead of saying "74 character limit OR ELSE", > I was suggesting "use some judgement". The point of my message was just to point to you that your messages are uncomfortable when not seen on a proper computer. >> I don't expect the Web to be hand-wrapped, nor books, nor papers done with LaTeX. > > The wrapping of books cannot be changed. > The wrapping of papers done with LaTeX is > *mostly* done by LaTeX, but it is very > common for people to have to rewrite text > to get good line breaks, even with (La)TeX. > One thing any experienced TeXnician is aware > of is that text written for one paper size > will *not* look good when reformatted for a > different size, *when formatted by (La)TeX*. > Especially tables. Eh? Prose will look good when reflowed under LaTeX algorithms. Why mention tables when I'm comparing LaTeX to mails in the context of reading prose? > Oddly enough, e-mail is NOT the Web, NOT a book, > and NOT a paper done with LaTeX (or Weird, or Lout, > or Troff). > > Anyone who finds my lines too short must have > terrible trouble with cereal boxes and newspapers. > (And I do know that e-mail isn't either of those. > Although it *is* very very much like the letters > to the Editor, which conventionally uses much > shorter lines than I do.) I'm having trouble with your too short lines because they look just plain wrong on a mobile phone. [1] And I don't eat cereals, I'm gluten-free, m'kay. >> Could we finally evolve from plain plain/text to format=flowed plain/text? >> >> http://joeclark.org/ffaq.html > > That's pretty much what the Mail program does _anyway_. > Basically, all format=flowed does is to take away > the author's freedom to use short lines; apart from > that it doesn't seem to change anything. No, your own mail client doesn't use any combination of encoding and content type that let the text reflow, hence why it looks bad on my phone, and just losing screen estate on my computer. [2] > The point about mobiles is well taken. I know I had > great trouble trying to read e-mail on an iPad using > a web mail interface. Mind you, that was because of > long lines, not short ones. But you know, there is > nothing that stops a mobile phone mail reader from > re-breaking paragraphs. Yes there is something that stops my mobile mail reader from re-breaking your paragraphs: your very email forbids it through its Content-Transfer-Encoding and Content-Type. Just look at the raw email you sent. Regards. [1] http://cl.ly/aHtt [2] http://cl.ly/aI8f From me@REDACTED Thu Mar 19 14:42:26 2015 From: me@REDACTED (Leandro Ostera) Date: Thu, 19 Mar 2015 10:42:26 -0300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <7D5D3F9F-A7CF-4DE2-998C-6FA70DF52FD4@gmail.com> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <7ACF549C-E479-4BA4-99DA-B22AFDBDE2C8@cs.otago.ac.nz> <7D5D3F9F-A7CF-4DE2-998C-6FA70DF52FD4@gmail.com> Message-ID: Can I just say that if someone takes the decorum and effort to write a response, regardless of how it's styled, it's only fair that I make the actually very small effort of reading it? Otherwise this topic is going to go on *forever* On the CoC, I'm quite new around this place but other than some well opinionated folks that after a while say "You're right.", I haven't read much trouble around the mailing list? I can't imagine it saying it's a welcoming community and then going like "Hey, thanks for your answer but since your lines are too long, I will totally just ignore your *actual* answer and just focus on bitching about lines being too long and whatnot" ? inconsistent line breaking on purpose. On Thu, Mar 19, 2015 at 10:22 AM, Anthony Ramine wrote: > Le 19 mars 2015 ? 02:23, Richard A. O'Keefe a ?crit : > > > I said I agreed with trying to keep lines short. > > And that's where I disagree. > > > On 19/03/2015, at 9:40 am, Anthony Ramine wrote: > >> I disagree. To me your messages look funny (lines *too* short) on my > main computer, and just plain unreadable on any mobile screen, because it > must wrap it furthermore to make it fit the screen. > > > > Well, I found your message uncomfortable to read > > because of its long lines. > > Why is your window so large that my message is uncomfortable? Why waste > the screen estate if you want it to show short lines? Want short lines? > Have a narrow window. > > > The point of my message was to *increase* authorial > > freedom compared with the proposed CoC rule. > > Instead of saying "74 character limit OR ELSE", > > I was suggesting "use some judgement". > > The point of my message was just to point to you that your messages are > uncomfortable when not seen on a proper computer. > > >> I don't expect the Web to be hand-wrapped, nor books, nor papers done > with LaTeX. > > > > The wrapping of books cannot be changed. > > The wrapping of papers done with LaTeX is > > *mostly* done by LaTeX, but it is very > > common for people to have to rewrite text > > to get good line breaks, even with (La)TeX. > > One thing any experienced TeXnician is aware > > of is that text written for one paper size > > will *not* look good when reformatted for a > > different size, *when formatted by (La)TeX*. > > Especially tables. > > Eh? Prose will look good when reflowed under LaTeX algorithms. Why mention > tables when I'm comparing LaTeX to mails in the context of reading prose? > > > Oddly enough, e-mail is NOT the Web, NOT a book, > > and NOT a paper done with LaTeX (or Weird, or Lout, > > or Troff). > > > > Anyone who finds my lines too short must have > > terrible trouble with cereal boxes and newspapers. > > (And I do know that e-mail isn't either of those. > > Although it *is* very very much like the letters > > to the Editor, which conventionally uses much > > shorter lines than I do.) > > I'm having trouble with your too short lines because they look just plain > wrong on a mobile phone. [1] > > And I don't eat cereals, I'm gluten-free, m'kay. > > >> Could we finally evolve from plain plain/text to format=flowed > plain/text? > >> > >> http://joeclark.org/ffaq.html > > > > That's pretty much what the Mail program does _anyway_. > > Basically, all format=flowed does is to take away > > the author's freedom to use short lines; apart from > > that it doesn't seem to change anything. > > No, your own mail client doesn't use any combination of encoding and > content type that let the text reflow, hence why it looks bad on my phone, > and just losing screen estate on my computer. [2] > > > The point about mobiles is well taken. I know I had > > great trouble trying to read e-mail on an iPad using > > a web mail interface. Mind you, that was because of > > long lines, not short ones. But you know, there is > > nothing that stops a mobile phone mail reader from > > re-breaking paragraphs. > > Yes there is something that stops my mobile mail reader from re-breaking > your paragraphs: your very email forbids it through its > Content-Transfer-Encoding and Content-Type. Just look at the raw email you > sent. > > Regards. > > [1] http://cl.ly/aHtt > [2] http://cl.ly/aI8f > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Leandro Ostera Github | LinkedIn | Facebook | @leostera -------------- next part -------------- An HTML attachment was scrubbed... URL: From e@REDACTED Thu Mar 19 17:01:21 2015 From: e@REDACTED (e@REDACTED) Date: Thu, 19 Mar 2015 17:01:21 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> Message-ID: <550AF2D1.2090507@bestmx.net> On 03/19/2015 12:30 PM, Peter Hickman wrote: > In an attempt to kill the 74 line length nonsense I give you a bunch of > lines that are all 74 characters long. I have ordered the lines by length > :) In relative terms the longest line, the 'W's is four times longer than > the shortest, the 'l's. hahaha! you've just exposed yourself! you are using a variable width font for e-mails?! OMG! From n.oxyde@REDACTED Thu Mar 19 17:04:33 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 19 Mar 2015 17:04:33 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550AF2D1.2090507@bestmx.net> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> Message-ID: Le 19 mars 2015 ? 17:01, e@REDACTED a ?crit : > hahaha! > you've just exposed yourself! > you are using a variable width font for e-mails?! > OMG! And what's wrong with that exactly? From e@REDACTED Thu Mar 19 17:10:52 2015 From: e@REDACTED (e@REDACTED) Date: Thu, 19 Mar 2015 17:10:52 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> Message-ID: <550AF50C.30606@bestmx.net> On 03/19/2015 05:04 PM, Anthony Ramine wrote: > Le 19 mars 2015 ? 17:01, e@REDACTED a ?crit : > >> hahaha! >> you've just exposed yourself! >> you are using a variable width font for e-mails?! >> OMG! > > And what's wrong with that exactly? allow me to quote the point which was already stated but you have cut it off, for unknown reason. > In an attempt to kill the 74 line length nonsense I give you a bunch > of lines that are all 74 characters long. I have ordered the lines > by length :) > In relative terms the longest line, the 'W's is four times longer > than the shortest, the 'l's. he is experiencing a problem (or at least he perceived it as a problem) isn't it enough to consider a solution? besides that, we share code snippets here, from time to time. P.S. i would not be surprised you you use variable width too :) and blame someone else for the same 74-characters problem. in order to kill me, tell me your font is serif-type? From n.oxyde@REDACTED Thu Mar 19 17:19:10 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 19 Mar 2015 17:19:10 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550AF50C.30606@bestmx.net> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> <550AF50C.30606@bestmx.net> Message-ID: <3783A124-B501-42B1-A05C-CD8E4DF95D6F@gmail.com> Le 19 mars 2015 ? 17:10, e@REDACTED a ?crit : > in order to kill me, tell me your font is serif-type? I don't know, given you participate to that thread I would expect that you also read it. Can't you see which type of font I use in the screenshots I linked of my mail clients? How is the fact that any hand-wrapping will invariably conflict with some configurations of mail clients related to Peter's font of choice? And what's wrong with using a proportional font? Do you realise that most prose produced by humans isn't monospaced? From e@REDACTED Thu Mar 19 17:33:10 2015 From: e@REDACTED (e@REDACTED) Date: Thu, 19 Mar 2015 17:33:10 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <3783A124-B501-42B1-A05C-CD8E4DF95D6F@gmail.com> References: <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> <550AF50C.30606@bestmx.net> <3783A124-B501-42B1-A05C-CD8E4DF95D6F@gmail.com> Message-ID: <550AFA46.20203@bestmx.net> On 03/19/2015 05:19 PM, Anthony Ramine wrote: > Le 19 mars 2015 ? 17:10, e@REDACTED a ?crit : > >> in order to kill me, tell me your font is serif-type? > > I don't know, given you participate to that thread I would expect that you also read it. Can't you see which type of font I use in the screenshots I linked of my mail clients? i am afraid you badly overestimate the value of your messages. From essen@REDACTED Thu Mar 19 17:39:08 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Mar 2015 17:39:08 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550AF50C.30606@bestmx.net> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> <550AF50C.30606@bestmx.net> Message-ID: <550AFBAC.6060208@ninenines.eu> On 03/19/2015 05:10 PM, e@REDACTED wrote: > besides that, we share code snippets here, from time to time. > > P.S. i would not be surprised you you use variable width too :) > and blame someone else for the same 74-characters problem. > in order to kill me, tell me your font is serif-type? And there is absolutely nothing wrong about using a variable width for code, just like there is nothing wrong about using it in emails. There are millions of programmers in the world who use not only variable width but also bold, italic and more (could call it "variable variable width", and are perfectly happy with the result. Telling people that what works perfectly fine for them is wrong is not going to convince them to join your side. -- Lo?c Hoguin http://ninenines.eu From e@REDACTED Thu Mar 19 17:44:41 2015 From: e@REDACTED (e@REDACTED) Date: Thu, 19 Mar 2015 17:44:41 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550AFBAC.6060208@ninenines.eu> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> <550AF50C.30606@bestmx.net> <550AFBAC.6060208@ninenines.eu> Message-ID: <550AFCF9.2040401@bestmx.net> >> besides that, we share code snippets here, from time to time. >> > And there is absolutely nothing wrong about using a variable width for > code, > Telling people that > what works perfectly fine for them is wrong is not going to convince > them to join your side. no-no-no! i didn't tel him that he has a problem. He said that variable width do not work well for him, but you keep omitting his statement. here goes the original quote: > In an attempt to kill the 74 line length nonsense I give you > a bunch of lines that are all 74 characters long. I have ordered > the lines by length :) > In relative terms the longest line, the 'W's is four times longer > than the shortest, the 'l's. From n.oxyde@REDACTED Thu Mar 19 17:51:24 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 19 Mar 2015 17:51:24 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550AFCF9.2040401@bestmx.net> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> <550AF50C.30606@bestmx.net> <550AFBAC.6060208@ninenines.eu> <550AFCF9.2040401@bestmx.net> Message-ID: Le 19 mars 2015 ? 17:33, e@REDACTED a ?crit : > i am afraid you badly overestimate the value of your messages. The pot calling the kettle black. You didn't reply to the rest, I could imagine that this is because you have nothing interesting to counter-argue, but that usually doesn't prevent you from posting. From e@REDACTED Thu Mar 19 18:05:16 2015 From: e@REDACTED (e@REDACTED) Date: Thu, 19 Mar 2015 18:05:16 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <550831B9.2000505@meetinghouse.net> <55097BE7.5050409@ninenines.eu> <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <550AF2D1.2090507@bestmx.net> <550AF50C.30606@bestmx.net> <550AFBAC.6060208@ninenines.eu> <550AFCF9.2040401@bestmx.net> Message-ID: <550B01CC.4060500@bestmx.net> > You didn't reply to the rest, I could imagine that this is because you have nothing interesting to counter-argue, but that usually doesn't prevent you from posting. well, you just have contradicted yourself: "You didn't reply" "that usually doesn't prevent you from posting" But. i am not going to continue this flame, consider yourself a winner. From nyarly@REDACTED Thu Mar 19 18:29:11 2015 From: nyarly@REDACTED (Judson Lester) Date: Thu, 19 Mar 2015 17:29:11 +0000 Subject: [erlang-questions] Reltool and escript Message-ID: Maybe this is a weird thing to do, but I'm experimenting with the reltool GUI, and running it from erl all the time was getting me down. So I wrote a little escript for it: main(_Args) -> {ok, Options} = file:consult("config.reltool"), reltool:start_link(Options). Those commands exactly work fine in an erl session, but when I run the escript, I get to a warning about various applications and their module name collisions, and then ?scripts/reltool ? terminated by signal SIGSEGV (Address boundary error) and then the script dies. Is there, maybe, a %%! setting I need to make or something? Judson -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeljalvarezmiguel@REDACTED Thu Mar 19 19:08:50 2015 From: angeljalvarezmiguel@REDACTED (Angel) Date: Thu, 19 Mar 2015 19:08:50 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: +1 > El 14/3/2015, a las 20:12, Laura M. Castro escribi?: > >> If I were to critique something here, it would be that the current CoC mixes >> text on social interaction[-1] (that is, how to behave with respect to other >> people) from mailing list etiquette (how to quote, how to make older mail >> readers happy[0]). > > I think this is a very good, constructive point. I agree. > > Also, from other emails in this thread, it seems to me that most of > the criticisms are directed towards the second part, so perhaps > splitting the two, as Jesper suggests, will not only benefit us as a > group if/when our activity extends to other areas/tools (i.e. the bug > tracker that he mentions), but also help us to reach consensus. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From eric.pailleau@REDACTED Thu Mar 19 21:35:48 2015 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Thu, 19 Mar 2015 21:35:48 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct Message-ID: Hi, I do not remember if someone pointed this url below : http://tools.ietf.org/html/rfc1855 There is already a RFC for the Netiquette, which is a better word than CoC, Mho. Regards Le 19 mars 2015 19:08, Angel a ?crit : > > +1 > > > El 14/3/2015, a las 20:12, Laura M. Castro escribi?: > > > >> If I were to critique something here, it would be that the current CoC mixes > >> text on social interaction[-1] (that is, how to behave with respect to other > >> people) from mailing list etiquette (how to quote, how to make older mail > >> readers happy[0]). > > > > I think this is a very good, constructive point. I agree. > > > > Also, from other emails in this thread, it seems to me that most of > > the criticisms are directed towards the second part, so perhaps > > splitting the two, as Jesper suggests, will not only benefit us as a > > group if/when our activity extends to other areas/tools (i.e. the bug > > tracker that he mentions), but also help us to reach consensus. > > _______________________________________________ > > 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 ok@REDACTED Thu Mar 19 22:38:58 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 20 Mar 2015 10:38:58 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <7D5D3F9F-A7CF-4DE2-998C-6FA70DF52FD4@gmail.com> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <7ACF549C-E479-4BA4-99DA-B22AFDBDE2C8@cs.otago.ac.nz> <7D5D3F9F-A7CF-4DE2-998C-6FA70DF52FD4@gmail.com> Message-ID: <5F71FB0F-1559-422F-BD44-BC5E6D92269C@cs.otago.ac.nz> On 20/03/2015, at 2:22 am, Anthony Ramine wrote: > > Why is your window so large that my message is uncomfortable? Why waste the screen estate if you want it to show short lines? Want short lines? Have a narrow window. My eyesight is not what it used to be. Sometimes I have to make things bigger to see details. It's a pain in the arse to have to keep changing the window size. (This is also why I find reading e-mail on a phone unimaginable, no matter what the length of the lines.) If I am looking at mail, I could use the *whole* of the screen and it would not be in any sense "wasted". >> Especially tables. > > Eh? Prose will look good when reflowed under LaTeX algorithms. Why mention tables when I'm comparing LaTeX to mails in the context of reading prose? You don't sound as if you have much experience with TeX. The big difference between TeX and Word is that when TeX is about to produce poor output, it *tells* you. That's what "underfull box" and "overfull box" are about. If your prose has long technical terms or embedded chunks of code you can expect a problem every few pages. Fix it for A4, and you WILL have to fix it again for US. Why mention tables? Because this is the first time anyone has mentioned 'prose'. I thought we were talking about e-mail. I've often received e-mail containing tables, and I've sent e-mail containing tables. Just today in a lecture I reflowed something for the sake of a student with worse eyesight than mine, and the line breaks were *horrible*. Above all, e-mail in a group devoted to a programming language will often contain "text" lines that are actually code. > No, your own mail client doesn't use any combination of encoding and content type that let the text reflow, hence why it looks bad on my phone, and just losing screen estate on my computer. [2] No, my own e-mail client *does* reflow, all the time. It's listed in the format=flowed FAQ as ones of the ones that supports f=f. > > Yes there is something that stops my mobile mail reader from re-breaking your paragraphs: your very email forbids it through its Content-Transfer-Encoding and Content-Type. Just look at the raw email you sent. I'm seeing Content-Type: text/plain; charset=windows-1252 ... Content-Transfer-Encoding: 7bit The character set I use is in fact *NOT* Windows-1252. "7bit" means that what I'm sending "is all represented as short lines of US-ASCII data". It says NOTHING about whether the receiver may reflow it. As for Content-Type: text/plain, "The primary subtype, "plain", indicates plain (unformatted) text. No special software is required to get the full meaning of the text, aside from support for the indicated character set." Again, this says that fancy formatting is not REQUIRED "to get the full meaning"; it says NOTHING about whether reflowing is ALLOWED. If your MUA doesn't reflow to fit your phone, that's a choice of its designers, NOT something forced by these headers. From ok@REDACTED Thu Mar 19 22:49:07 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 20 Mar 2015 10:49:07 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5F71FB0F-1559-422F-BD44-BC5E6D92269C@cs.otago.ac.nz> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <7ACF549C-E479-4BA4-99DA-B22AFDBDE2C8@cs.otago.ac.nz> <7D5D3F9F-A7CF-4DE2-998C-6FA70DF52FD4@gmail.com> <5F71FB0F-1559-422F-BD44-BC5E6D92269C@cs.otago.ac.nz> Message-ID: <979EA78C-DCB2-4C49-B855-1FAEB63E460E@cs.otago.ac.nz> > On 20/03/2015, at 2:22 am, Anthony Ramine wrote: >> >> Why is your window so large that my message is uncomfortable? Why waste the screen estate if you want it to show short lines? Want short lines? Have a narrow window. There is another reason I forgot to mention. The MUA I use has two principal panes. The upper one lists sender name, subject, and when received, all of which are highly relevant for deciding which message to read. The lower pane, where the messages actually appear, is constrained to be the same width as the upper one. Of course that's an idiotic design. Of course the upper pane and the lower pane should be separate windows. But it's not an open source program, so I cannot fix that. From n.oxyde@REDACTED Fri Mar 20 03:29:56 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 20 Mar 2015 03:29:56 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5F71FB0F-1559-422F-BD44-BC5E6D92269C@cs.otago.ac.nz> References: <59308D52-6BA9-4A07-81B0-33FBD1A871C4@cs.otago.ac.nz> <7ACF549C-E479-4BA4-99DA-B22AFDBDE2C8@cs.otago.ac.nz> <7D5D3F9F-A7CF-4DE2-998C-6FA70DF52FD4@gmail.com> <5F71FB0F-1559-422F-BD44-BC5E6D92269C@cs.otago.ac.nz> Message-ID: <1CFED5F7-F248-4C99-8830-F71CB2605981@gmail.com> Le 19 mars 2015 ? 22:38, Richard A. O'Keefe a ?crit : > > On 20/03/2015, at 2:22 am, Anthony Ramine wrote: >> >> Why is your window so large that my message is uncomfortable? Why waste the screen estate if you want it to show short lines? Want short lines? Have a narrow window. > > My eyesight is not what it used to be. > Sometimes I have to make things bigger to see details. > It's a pain in the arse to have to keep changing the > window size. > (This is also why I find reading e-mail on a phone > unimaginable, no matter what the length of the lines.) Sure, but that doesn't mean the mailing-list should follow conventions that makes the experience bad for those with a better eyesight. > If I am looking at mail, I could use the *whole* of > the screen and it would not be in any sense "wasted". > >>> Especially tables. >> >> Eh? Prose will look good when reflowed under LaTeX algorithms. Why mention tables when I'm comparing LaTeX to mails in the context of reading prose? > > You don't sound as if you have much experience with TeX. > The big difference between TeX and Word is that when TeX > is about to produce poor output, it *tells* you. That's > what "underfull box" and "overfull box" are about. > If your prose has long technical terms or embedded chunks > of code you can expect a problem every few pages. > Fix it for A4, and you WILL have to fix it again for US. > > Why mention tables? Because this is the first time > anyone has mentioned 'prose'. I thought we were talking > about e-mail. I've often received e-mail containing > tables, and I've sent e-mail containing tables. > > Just today in a lecture I reflowed something for the > sake of a student with worse eyesight than mine, and > the line breaks were *horrible*. > > Above all, e-mail in a group devoted to a programming > language will often contain "text" lines that are > actually code. Given the state of emails, there will always be cases where it's hard to read on some MUAs, that doesn't mean the most common case, i.e. prose, should be badly handled. Just like how most flowing of plain prose is not a problem in LaTeX. >> No, your own mail client doesn't use any combination of encoding and content type that let the text reflow, hence why it looks bad on my phone, and just losing screen estate on my computer. [2] > > No, my own e-mail client *does* reflow, all the time. > It's listed in the format=flowed FAQ as ones of the > ones that supports f=f. From a quick reading of RFC2646, the format=flowed parameter was introduced because of the problem I described, it even talks about an "Embarrassing Line Wrap". The parameter was introduced to distinguish reflowing text from other text/plain contents because MUAs should not be expected to reflow plain old emails as the ones you send. >> Yes there is something that stops my mobile mail reader from re-breaking your paragraphs: your very email forbids it through its Content-Transfer-Encoding and Content-Type. Just look at the raw email you sent. > > I'm seeing > > Content-Type: text/plain; > charset=windows-1252 > ... > Content-Transfer-Encoding: 7bit > > The character set I use is in fact *NOT* Windows-1252. > "7bit" means that what I'm sending > "is all represented as short lines of US-ASCII data". > It says NOTHING about whether the receiver may reflow it. > > As for Content-Type: text/plain, > "The primary subtype, "plain", indicates plain (unformatted) > text. No special software is required to get the full > meaning of the text, aside from support for the indicated > character set." > Again, this says that fancy formatting is not REQUIRED > "to get the full meaning"; it says NOTHING about whether > reflowing is ALLOWED. Note that your Content-Type doesn't include format=flowed. I mentioned Content-Transfer-Encoding because if you look at my own emails, they don't include format=flowed either. Instead, they send the mails as quoted-printable and all return lines required to be a valid email are escaped with an equal sign; then the recipient MUA reflows the text to make my actual long lines fit. I would rather have format=flowed but at least most MUAs can still properly render it, including the more modern (and as usual, worse, I agree) ones. > If your MUA doesn't reflow to fit your phone, > that's a choice of its designers, NOT something > forced by these headers. It doesn't reflow because your mail doesn't include format=flowed, that is not a choice of its designers in my book. From gguthrie@REDACTED Fri Mar 20 09:30:48 2015 From: gguthrie@REDACTED (Gordon Guthrie) Date: Fri, 20 Mar 2015 08:30:48 +0000 Subject: [erlang-questions] Reverse Compiling Erlang AST to Erlang Message-ID: Folks I am generating some Erlang modules on the fly by generating ASTs. For expository and code review processes I would like to be able to output the corresponding Erlang source code. I have a hazy memory that this can be done, but damned if I can remember how... Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Fri Mar 20 11:12:03 2015 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 20 Mar 2015 06:12:03 -0400 Subject: [erlang-questions] Reverse Compiling Erlang AST to Erlang In-Reply-To: References: Message-ID: Try this: https://github.com/saleyn/util/blob/master/src/decompiler.erl Regards, Serge On Fri, Mar 20, 2015 at 4:30 AM, Gordon Guthrie wrote: > Folks > > I am generating some Erlang modules on the fly by generating ASTs. > > For expository and code review processes I would like to be able to output > the corresponding Erlang source code. > > I have a hazy memory that this can be done, but damned if I can remember > how... > > Gordon > > _______________________________________________ > 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 20 13:05:18 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 20 Mar 2015 13:05:18 +0100 Subject: [erlang-questions] Reverse Compiling Erlang AST to Erlang In-Reply-To: References: Message-ID: Le 20 mars 2015 ? 09:30, Gordon Guthrie a ?crit : > Folks > > I am generating some Erlang modules on the fly by generating ASTs. > > For expository and code review processes I would like to be able to output the corresponding Erlang source code. > > I have a hazy memory that this can be done, but damned if I can remember how... Use erl_pp or erl_prettypr, depending on which AST you generate. From vincent.dephily@REDACTED Fri Mar 20 13:16:51 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 20 Mar 2015 13:16:51 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550A738E.704@ericsson.com> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> Message-ID: <18777803.qjqNZhNtEs@moltowork> On Thursday 19 March 2015 07:58:22 Bengt Kleberg wrote: > When advocating top posts as better than inline quotes, one reason > mentioned is that it is possible to use inline quotes to manipulate the > discussion whereas a top post will keep all quotes un-edited below. > Sounds logical. It isn't logical. Quotes can be edited and manipulated just as easily wether they're partial or in full, inline or at the bottom. The only reason people are less afraid of manipulative editing in the toppost case is that readers will likely not read the quoted text at all, and therefore miss out on any manipulation. If you're afraid of manipulation, read the original, not the quote. That said, if somebody intentionally misquotes to change the quoted text's meaning, it calls for moderator action. > The retort to this argument is that to prevent improper quotations no > quotes should be allowed. > I can not make the leap from, if keeping all text is better than editing > it, then the really large edit of removing all text is even better. The whole purpose of quoting (inline, top, partial, full, whatever) is to provide context. I think we can all agree on that ? As it happens, on a mailing list (especially one with public archives), the context of who you're replying to and the full original message is already there. So including the whole original message in your reply doesn't add any usefull context. Worse : it distracts the reader's attention and is therefore worse than not quoting anything. On the other hand, inline quoting (part of) the original message adds useful context. It pinpoints specific parts of the message that you're reacting to. It makes email exchanges feel more like a natural discussion (where people interrupt each other all the time) than if sending long essays back and forth. The community will collecively take more time reading your email than it took you to write it. So Just like when writing maintainable code, it's worth spending time to make your message as readable as possible. Inline quoting helps, top posting doesn't. -- Vincent de Phily From vincent.dephily@REDACTED Fri Mar 20 13:36:02 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 20 Mar 2015 13:36:02 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550A6E32.6080306@ericsson.com> References: <18081302.eI0vuKfqsD@moltowork> <550A6E32.6080306@ericsson.com> Message-ID: <17618904.xoVQttYHfG@moltowork> On Thursday 19 March 2015 07:35:30 Bengt Kleberg wrote: > A top post with all the previous content below can save me time. It acts > like a cache. I do not have to locate the right email in the archive if > I want to check something. I'm happy for you that you saved a precious 5 seconds not bothering with inline-quoting (or 1 second if your mailer knows to only quote the highlighted text when replying). I'm less happy that I had to spend 0.5 seconds double-checking the quoted part to make sure there wasn't any actual content left (thankfully I trust that you didn't misquote me, and didn't waste time checking that). If more than 10 people have read your email and my statistics are somewhat correct, the decision to top-post has caused a net time loss for the community. Please, if you don't have time for inline quoting, don't quote at all. If you can't configure your mailer to do the right thing, hit "Ctrl-A Suppr" before you start typing. -- Vincent de Phily From valentin@REDACTED Fri Mar 20 14:09:45 2015 From: valentin@REDACTED (Valentin Micic) Date: Fri, 20 Mar 2015 15:09:45 +0200 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <18777803.qjqNZhNtEs@moltowork> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> Message-ID: <88861A65-20A3-40D2-992E-29ED75234BF9@pixie.co.za> > The whole purpose of quoting (inline, top, partial, full, whatever) is to > provide context. I think we can all agree on that ? By just reading the above, I do not think you would be able to tell if the discussion was about top-posting vs in-line quoting, or we were just discussing about purpose quoting in general. V/ From e@REDACTED Fri Mar 20 14:44:10 2015 From: e@REDACTED (e@REDACTED) Date: Fri, 20 Mar 2015 14:44:10 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <88861A65-20A3-40D2-992E-29ED75234BF9@pixie.co.za> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <88861A65-20A3-40D2-992E-29ED75234BF9@pixie.co.za> Message-ID: <550C242A.40200@bestmx.net> On 03/20/2015 02:09 PM, Valentin Micic wrote: >> The whole purpose of quoting (inline, top, partial, full, whatever) is to >> provide context. I think we can all agree on that ? > > > if the discussion was about top-posting vs in-line quoting, or we were just discussing about purpose quoting in general. the purpose determines the implementation a context have to precede a message From ulf@REDACTED Fri Mar 20 14:57:20 2015 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 20 Mar 2015 14:57:20 +0100 Subject: [erlang-questions] Reverse Compiling Erlang AST to Erlang In-Reply-To: References: Message-ID: There is some stuff in parse_trans to help. 1. parse_trans_pp.erl, which is designed to be used via escript as well https://github.com/uwiger/parse_trans/blob/master/doc/parse_trans_pp.md 2. parse_trans_codegen.erl, for generating ASTs. https://github.com/uwiger/parse_trans/blob/master/doc/parse_trans_codegen.md https://github.com/uwiger/parse_trans/blob/master/examples/ex_codegen.erl 3. Accidentally undocumented are the compile options ?pt_pp_src? and ?pt_log_forms?, which instruct the parse_trans transforms to either pretty-print the resulting source, or to write the AST, into a separate file. BR, Ulf W > On 20 Mar 2015, at 09:30, Gordon Guthrie wrote: > > Folks > > I am generating some Erlang modules on the fly by generating ASTs. > > For expository and code review processes I would like to be able to output the corresponding Erlang source code. > > I have a hazy memory that this can be done, but damned if I can remember how... > > Gordon > _______________________________________________ > 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 valentin@REDACTED Fri Mar 20 15:01:33 2015 From: valentin@REDACTED (Valentin Micic) Date: Fri, 20 Mar 2015 16:01:33 +0200 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <550C242A.40200@bestmx.net> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <88861A65-20A3-40D2-992E-29ED75234BF9@pixie.co.za> <550C242A.40200@bestmx.net> Message-ID: <286A08AB-5E22-4BC7-9D25-C2D7BA810903@pixie.co.za> And violets are blue? Did you see what just happened here? On 20 Mar 2015, at 3:44 PM, e@REDACTED wrote: > On 03/20/2015 02:09 PM, Valentin Micic wrote: >>> The whole purpose of quoting (inline, top, partial, full, whatever) is to >>> provide context. I think we can all agree on that ? >> >> >> if the discussion was about top-posting vs in-line quoting, or we were just discussing about purpose quoting in general. > > the purpose determines the implementation > a context have to precede a message > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vincent.dephily@REDACTED Fri Mar 20 15:34:17 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 20 Mar 2015 15:34:17 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <88861A65-20A3-40D2-992E-29ED75234BF9@pixie.co.za> References: <18777803.qjqNZhNtEs@moltowork> <88861A65-20A3-40D2-992E-29ED75234BF9@pixie.co.za> Message-ID: <1505371.ZDRTPpM0Hs@moltowork> On Friday 20 March 2015 15:09:45 Valentin Micic wrote: > > The whole purpose of quoting (inline, top, partial, full, whatever) is to > > provide context. I think we can all agree on that ? > > By just reading the above, I do not think you would be able to tell if the > discussion was about top-posting vs in-line quoting, or we were just > discussing about purpose quoting in general. The two are not really separable : you do something for a purpose. My argument is that on a mailing list, the only purpose of including (part of) the original text in your reply is to provide context, and that this purpose isn't served well by top-posting. -- Vincent de Phily From community-manager@REDACTED Fri Mar 20 16:47:48 2015 From: community-manager@REDACTED (Bruce Yinhe) Date: Fri, 20 Mar 2015 16:47:48 +0100 Subject: [erlang-questions] Changes to Erlang.org Code of Conduct Message-ID: Hello everyone, There has been some attention given to the Code of Conduct since its publication. We highly appreciate the feedback from the members of the community. We are aware that certain sections have caused confusion and therefore would like to clarify the intent of the Code of Conduct and to announce some changes in the text. 1. The Code of Conduct was created on request from community members. 2. The style policy is now removed from the Code of Conduct. It was mistakenly placed in the Code of Conduct as it was originally intended as a sole ?recommendation? or ?guideline?. 3. We appreciate the good work and conduct of all our community members. Over the course of the past seventeen years, there has never been an incident of bad conduct of any community member. For those who never heard from a moderator, there is a very low probability they will hear from one. 4. The Code of Conduct is open to discussion. You are welcome to submit your suggestions of edits to community-manager@REDACTED With the aim of creating a welcoming, inclusive climate within the erlang.org community, we deem a Code of Conduct necessary and important to communicate our values to the people in our community, and to people who might be considering joining our community. Since our expectations of what is appropriate are not always in line with one another, a policy like this sets the ground rules and ensures that everyone is on the same page without any grey areas. You may read the updated Code of Conduct here http://www.erlang.org/download/erlang_org_code_of_conduct.txt Best regards -- Bruce Yinhe Erlang Community Manager Industrial Erlang User Group community-manager@REDACTED +46 72 311 43 89 -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Mar 20 17:12:00 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 20 Mar 2015 17:12:00 +0100 Subject: [erlang-questions] Changes to Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <550C46D0.8000404@ninenines.eu> On 03/20/2015 04:47 PM, Bruce Yinhe wrote: > 1. The Code of Conduct was created on request from community members. ... > 3. We appreciate the good work and conduct of all our community members. > Over the course of the past seventeen years, there has never been an > incident of bad conduct of any community member. Haven't seen anyone request it (it's in private I'm sure), and from what you say it doesn't solve any immediate problem either. On the other hand a public bug tracker has been requested numerous times, enough times that it gets tiring to ask, and would have an immediate benefit. Skewed priorities? > 2. The style policy is now removed from the Code of Conduct. It was > mistakenly placed in the Code of Conduct as it was originally intended > as a sole ?recommendation? or ?guideline?. Good. Take that, mutt users! > 4. The Code of Conduct is open to discussion. You are welcome to submit > your suggestions of edits to community-manager@REDACTED > . > > With the aim of creating a welcoming, inclusive climate within the > erlang.org community, we deem a Code of Conduct > necessary and important to communicate our values to the people in our > community, and to people who might be considering joining our community. > Since our expectations of what is appropriate are not always in line > with one another, a policy like this sets the ground rules and ensures > that everyone is on the same page without any grey areas. As many have pointed out in the previous thread, it's too opaque. Discussing that doesn't seem to have changed much. It doesn't have grey areas but who moderates, how, fair trial process, redeeming process and transparency all are a complete blackout. "Send an email to 'address' and hope he is in a good mood" is not a good redeeming process. Cheers, -- Lo?c Hoguin http://ninenines.eu From vincent.dephily@REDACTED Fri Mar 20 17:32:44 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 20 Mar 2015 17:32:44 +0100 Subject: [erlang-questions] Changes to Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <1747749.ihRAABayMR@moltowork> On Friday 20 March 2015 16:47:48 Bruce Yinhe wrote: > 2. The style policy is now removed from the Code of Conduct. It was > mistakenly placed in the Code of Conduct as it was originally intended as a > sole ?recommendation? or ?guideline?. There's still a reference to posting style in the CoC, leading to a dangling pointer : > If you want to answer, but prefer the posting style described below, state > that at the end and link to this article for explanation. The preceding paragraph is IMHO ok to keep. -- Vincent de Phily From nx@REDACTED Sat Mar 21 23:52:57 2015 From: nx@REDACTED (nx) Date: Sat, 21 Mar 2015 18:52:57 -0400 Subject: [erlang-questions] Mnesia Callbacks? Message-ID: I'm trying to make a simple module for 1) creating a mnesia table and 2) seed the created table with default data. I'm not finding anything in the docs on passing a callback module option into create_table or anything. Currently I'm using this to create and seed my table: reset() -> setup(), timer:sleep(3000), seed(). Any ideas? From vances@REDACTED Sun Mar 22 04:48:07 2015 From: vances@REDACTED (Vance Shipley) Date: Sun, 22 Mar 2015 09:18:07 +0530 Subject: [erlang-questions] Mnesia Callbacks? In-Reply-To: References: Message-ID: On Sun, Mar 22, 2015 at 4:22 AM, nx wrote: > reset() -> > setup(), > timer:sleep(3000), > seed(). reset() -> setup(), case mnesia:wait_for_tables([table_name], 3000) of ok -> seed(); {timeout, _} -> {error, timeout}; {error, Reason} -> {error, Reason} end. -- -Vance From nx@REDACTED Sun Mar 22 05:06:03 2015 From: nx@REDACTED (nx) Date: Sun, 22 Mar 2015 00:06:03 -0400 Subject: [erlang-questions] Mnesia Callbacks? In-Reply-To: References: Message-ID: That worked perfectly. I must have not looked at the docs closely enough because mnesia:wait_for_tables seems like an obvious function name. Thanks, Vance! On Sat, Mar 21, 2015 at 11:48 PM, Vance Shipley wrote: > On Sun, Mar 22, 2015 at 4:22 AM, nx wrote: >> reset() -> >> setup(), >> timer:sleep(3000), >> seed(). > > reset() -> > setup(), > case mnesia:wait_for_tables([table_name], 3000) of > ok -> > seed(); > {timeout, _} -> > {error, timeout}; > {error, Reason} -> > {error, Reason} > end. > > -- > -Vance From max.lapshin@REDACTED Sun Mar 22 10:01:32 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Mar 2015 12:01:32 +0300 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed Message-ID: Hi. I've met again performance problem with io_lib:format. iso8601({{Y,Mo,D}, {H,Mn,S}}) -> FmtStr = "~4.10.0B-~2.10.0B-~2.10.0BT~2.10.0B:~2.10.0B:~2.10.0BZ", IsoStr = io_lib:format(FmtStr, [Y, Mo, D, H, Mn, S]), list_to_binary(IsoStr). Such code is a 0,01% of business logic of one small part of flussonic, but it takes about 95% of time to make 10% of text output. I've solved this problem via https://github.com/maxlapshin/io_libc but I'm not sure that it is a best way to do. Maybe this is better solved in pure erlang? Perhaps I'm not alone with this problem and somebody has some better idea than just exposing fprinf via nif? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Sun Mar 22 10:22:42 2015 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Sun, 22 Mar 2015 02:22:42 -0700 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: References: Message-ID: Hi Max, How about just generating an iolist? You could write a simple function for this FmtStr case that outputs an iolist and thus does not do too much copying and allocation. Also how much faster is io_libc/format/2 compared to io_libc? Just curious. Cheers, -- Pierre Fenoll On 22 March 2015 at 02:01, Max Lapshin wrote: > Hi. > > I've met again performance problem with io_lib:format. > > iso8601({{Y,Mo,D}, {H,Mn,S}}) -> > FmtStr = "~4.10.0B-~2.10.0B-~2.10.0BT~2.10.0B:~2.10.0B:~2.10.0BZ", > IsoStr = io_lib:format(FmtStr, [Y, Mo, D, H, Mn, S]), > list_to_binary(IsoStr). > > > Such code is a 0,01% of business logic of one small part of flussonic, but > it takes about 95% of time to make 10% of text output. > > > I've solved this problem via https://github.com/maxlapshin/io_libc but > I'm not sure that it is > a best way to do. Maybe this is better solved in pure erlang? > > > Perhaps I'm not alone with this problem and somebody has some better idea > than just exposing fprinf via nif? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sun Mar 22 10:27:38 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Mar 2015 12:27:38 +0300 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: References: Message-ID: I don't remember exact difference between io_libc:format and io_lib:format but it was between 100 to 1000 on generating CSV file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandrashekhar.mullaparthi@REDACTED Sun Mar 22 11:10:18 2015 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Sun, 22 Mar 2015 10:10:18 +0000 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: References: Message-ID: Hi Max, Is something like this not good enough in terms of speed? iso8601({{Y,Mo,D}, {H,Mn,S}}) -> list_to_binary([integer_to_list(Y), $-, two_digit_str(Mo), $-, two_digit_str(D), $T, two_digit_str(H), $:, two_digit_str(Mn), $:, two_digit_str(S), $Z]). two_digit_str(X) when X < 10 -> [$0 | integer_to_list(X)]; two_digit_str(X) -> integer_to_list(X). cheers, Chandru On 22 March 2015 at 09:01, Max Lapshin wrote: > Hi. > > I've met again performance problem with io_lib:format. > > iso8601({{Y,Mo,D}, {H,Mn,S}}) -> > FmtStr = "~4.10.0B-~2.10.0B-~2.10.0BT~2.10.0B:~2.10.0B:~2.10.0BZ", > IsoStr = io_lib:format(FmtStr, [Y, Mo, D, H, Mn, S]), > list_to_binary(IsoStr). > > > Such code is a 0,01% of business logic of one small part of flussonic, but > it takes about 95% of time to make 10% of text output. > > > I've solved this problem via https://github.com/maxlapshin/io_libc but > I'm not sure that it is > a best way to do. Maybe this is better solved in pure erlang? > > > Perhaps I'm not alone with this problem and somebody has some better idea > than just exposing fprinf via nif? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sun Mar 22 11:29:31 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Mar 2015 13:29:31 +0300 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: References: Message-ID: My trivial bench shows that your code is best: https://gist.github.com/maxlapshin/e7a18c997a6bac555171 ./bench.erl native: 2015-03-21T17:30:57Z nif: 2015-03-21T17:30:57Z erlang: 2015-03-21T17:30:57Z native: 6 nif: 2 erlang: 0 Will check it in real load, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sun Mar 22 11:45:35 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Mar 2015 13:45:35 +0300 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: References: Message-ID: Benchmarking closer to real data showed that generating one playlist takes: 140000 with io_libc 115000 with your implementation. It is really good! Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sun Mar 22 11:51:13 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 22 Mar 2015 11:51:13 +0100 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: References: Message-ID: <550E9EA1.4010209@ninenines.eu> If a binary isn't needed then the list_to_binary can be removed entirely, and for bonus points integer_to_binary can be used instead of integer_to_list to save some memory. If a binary is needed it should be quicker to build the binary directly instead of having an intermediate list. If benchmarks show the same time to produce both you still win because you then don't have to GC intermediate representations (assuming no optimization takes place). Cheers, On 03/22/2015 11:10 AM, Chandru wrote: > Hi Max, > > Is something like this not good enough in terms of speed? > > iso8601({{Y,Mo,D}, {H,Mn,S}}) -> > list_to_binary([integer_to_list(Y), $-, > two_digit_str(Mo), $-, > two_digit_str(D), $T, > two_digit_str(H), $:, > two_digit_str(Mn), $:, > two_digit_str(S), $Z]). > > two_digit_str(X) when X < 10 -> > [$0 | integer_to_list(X)]; > two_digit_str(X) -> > integer_to_list(X). > > > cheers, > Chandru > > > On 22 March 2015 at 09:01, Max Lapshin > wrote: > > Hi. > > I've met again performance problem with io_lib:format. > > iso8601({{Y,Mo,D}, {H,Mn,S}}) -> > FmtStr = "~4.10.0B-~2.10.0B-~2.10.0BT~2.10.0B:~2.10.0B:~2.10.0BZ", > IsoStr = io_lib:format(FmtStr, [Y, Mo, D, H, Mn, S]), > list_to_binary(IsoStr). > > > Such code is a 0,01% of business logic of one small part of > flussonic, but it takes about 95% of time to make 10% of text output. > > > I've solved this problem via https://github.com/maxlapshin/io_libc > but I'm not sure that it is > a best way to do. Maybe this is better solved in pure erlang? > > > Perhaps I'm not alone with this problem and somebody has some better > idea than just exposing fprinf via nif? > > _______________________________________________ > 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 > -- Lo?c Hoguin http://ninenines.eu From max.lapshin@REDACTED Sun Mar 22 12:20:13 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Mar 2015 14:20:13 +0300 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: <550E9EA1.4010209@ninenines.eu> References: <550E9EA1.4010209@ninenines.eu> Message-ID: Very good. Optimized to direct binary packing. Next question: what is the best way to refuse from calendar: to something fast, but not going to NIF gmtime? Need to convert utc to datetime. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sun Mar 22 12:42:30 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Mar 2015 14:42:30 +0300 Subject: [erlang-questions] Proper replacement for io_lib:format due to low speed In-Reply-To: References: <550E9EA1.4010209@ninenines.eu> Message-ID: Very funny. After I've changed io_lib to io_libc and then to hardcoded packing by Chandru happened very funny situation. Client (strange client) is requesting very long HLS playlist very often. Before fixes flussonic hanged on about 5 request per second. Now flussonic can send about 15 requests per second without even warming CPU. Each request is about 700 kbytes, so this broken client is getting about 90 megabits per second. -------------- next part -------------- An HTML attachment was scrubbed... URL: From minostro@REDACTED Sun Mar 22 21:56:48 2015 From: minostro@REDACTED (Milton Inostroza) Date: Sun, 22 Mar 2015 15:56:48 -0500 Subject: [erlang-questions] Encoding issues with xmerl Message-ID: <075C4C88-DCD9-43F5-9A8B-8DC58192C391@minostro.com> Hi All, I'm just trying to write a small SOAP client to consume a very single soap endpoint in Erlang. I'm able to get the response from the server which is as follows: "<?xml version=\"1.0\" encoding=\"utf-16\"?>\r\n<CurrentWeather>\r\n <Location>CHICAGO/WAUKEGAN REGIONAL, IL, United States (KUGN) 42-25N 087-52W</Location>\r\n <Time>Mar 22, 2015 - 03:55 PM EDT / 2015.03.22 1955 UTC</Time>\r\n <Wind> from the NE (050 degrees) at 9 MPH (8 KT):0</Wind>\r\n <Visibility> 10 mile(s):0</Visibility>\r\n <SkyConditions> mostly cloudy</SkyConditions>\r\n <Temperature> 30.0 F (-1.1 C)</Temperature>\r\n <Wind>Windchill: 21 F (-6 C):1</Wind>\r\n <DewPoint> 14.0 F (-10.0 C)</DewPoint>\r\n <RelativeHumidity> 50%</RelativeHumidity>\r\n <Pressure> 30.28 in. Hg (1025 hPa)</Pressure>\r\n <Status>Success</Status>\r\n</CurrentWeather>" I'm able to get a proper Erlang tuple by calling xmerl_scan:string(Response). I get problems when trying to convert the Body part of the response which is another xml document. The error that I get is the following: {XmlData, _} = xmerl_scan:string(lists:append(Data)). 3899- fatal: expected_element_start_tag ** exception exit: {fatal,{expected_element_start_tag,{file,file_name_unknown}, {line,2}, {col,2}}} in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 567) in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) As a workaround I'm calling the xmerl_scan:string function passing a second parameter: [{encoding, latin1}] This allows xmerl to successfully convert the string into an Erlang tuple, which makes me believe that there is a encoding problem somewhere. My script looks like this: application:start(inets). SoapBody = "ChicagoUnited States". SoapEnvelope = lists:append([ "", SoapBody, ""] ). {ok, {{_, _, _}, _, ResponseBody}} = httpc:request(post, {"http://www.webservicex.net/globalweather.asmx", [], "text/xml", SoapEnvelope}, [], []). {Xml, _} = xmerl_scan:string(ResponseBody). {_, _, [{_, _, [{_, _, [{_, [], Data}]}]}]} = xmerl_lib:simplify_element(Xml). {XmlData, _} = xmerl_scan:string(lists:append(Data), [{encoding, latin1}]). FinalResult = xmerl_lib:simplify_element(XmlData). I would really like to avoid calling xmerl_scan:string with the second argument, but I cannot figure how to do that. Any ideas? Thanks, --Milton From nx@REDACTED Sun Mar 22 22:04:59 2015 From: nx@REDACTED (nx) Date: Sun, 22 Mar 2015 17:04:59 -0400 Subject: [erlang-questions] Encoding issues with xmerl In-Reply-To: <075C4C88-DCD9-43F5-9A8B-8DC58192C391@minostro.com> References: <075C4C88-DCD9-43F5-9A8B-8DC58192C391@minostro.com> Message-ID: I've successfully used the detergent library (https://github.com/devinus/detergent) for consuming SOAP resources. That may yield better results than manually parsing XML with xmerl. On Sun, Mar 22, 2015 at 4:56 PM, Milton Inostroza wrote: > Hi All, > > I'm just trying to write a small SOAP client to consume a very single soap endpoint in Erlang. I'm able to get the response from the server which is as follows: > > "<?xml version=\"1.0\" encoding=\"utf-16\"?>\r\n<CurrentWeather>\r\n <Location>CHICAGO/WAUKEGAN REGIONAL, IL, United States (KUGN) 42-25N 087-52W</Location>\r\n <Time>Mar 22, 2015 - 03:55 PM EDT / 2015.03.22 1955 UTC</Time>\r\n <Wind> from the NE (050 degrees) at 9 MPH (8 KT):0</Wind>\r\n <Visibility> 10 mile(s):0</Visibility>\r\n <SkyConditions> mostly cloudy</SkyConditions>\r\n <Temperature> 30.0 F (-1.1 C)</Temperature>\r\n <Wind>Windchill: 21 F (-6 C):1</Wind>\r\n <DewPoint> 14.0 F (-10.0 C)</DewPoint>\r\n <RelativeHumidity> 50%</RelativeHumidity>\ > r\n <Pressure> 30.28 in. Hg (1025 hPa)</Pressure>\r\n <Status>Success</Status>\r\n</CurrentWeather>" > > I'm able to get a proper Erlang tuple by calling xmerl_scan:string(Response). I get problems when trying to convert the Body part of the response which is another xml document. The error that I get is the following: > > {XmlData, _} = xmerl_scan:string(lists:append(Data)). > 3899- fatal: expected_element_start_tag > ** exception exit: {fatal,{expected_element_start_tag,{file,file_name_unknown}, > {line,2}, > {col,2}}} > in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) > in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 567) > in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) > > As a workaround I'm calling the xmerl_scan:string function passing a second parameter: [{encoding, latin1}] This allows xmerl to successfully convert the string into an Erlang tuple, which makes me believe that there is a encoding problem somewhere. > > My script looks like this: > > application:start(inets). > SoapBody = "ChicagoUnited States". > SoapEnvelope = lists:append([ > "", > SoapBody, > ""] > ). > {ok, {{_, _, _}, _, ResponseBody}} = httpc:request(post, {"http://www.webservicex.net/globalweather.asmx", [], "text/xml", SoapEnvelope}, [], []). > {Xml, _} = xmerl_scan:string(ResponseBody). > {_, _, [{_, _, [{_, _, [{_, [], Data}]}]}]} = xmerl_lib:simplify_element(Xml). > {XmlData, _} = xmerl_scan:string(lists:append(Data), [{encoding, latin1}]). > FinalResult = xmerl_lib:simplify_element(XmlData). > > I would really like to avoid calling xmerl_scan:string with the second argument, but I cannot figure how to do that. Any ideas? > > Thanks, > > --Milton > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From hm@REDACTED Mon Mar 23 10:31:01 2015 From: hm@REDACTED (=?UTF-8?Q?H=C3=A5kan_Mattsson?=) Date: Mon, 23 Mar 2015 10:31:01 +0100 Subject: [erlang-questions] Reltool and escript Message-ID: I don't know about the SIGSEGV. ? But ? ?a? s the script is written, it will end prematurely. A simple solution is to just add timer:sleep(infinity) in the end of the script. A better solution is to wait for reltool to end before you exit the script. Then you may exit the script with different status codes /H?kan On Thu, Mar 19, 2015 at 6:29 PM, Judson Lester wrote: > Maybe this is a weird thing to do, but I'm experimenting with the reltool > GUI, and running it from erl all the time was getting me down. So I wrote a > little escript for it: > > main(_Args) -> > {ok, Options} = file:consult("config.reltool"), > reltool:start_link(Options). > > Those commands exactly work fine in an erl session, but when I run the > escript, I get to a warning about various applications and their module > name collisions, and then > > ?scripts/reltool ? terminated by signal SIGSEGV (Address boundary error) > > and then the script dies. > > Is there, maybe, a %%! setting I need to make or something? > > Judson > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Mon Mar 23 15:58:37 2015 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 23 Mar 2015 15:58:37 +0100 Subject: [erlang-questions] Change of license from EPL to APL 2.0 Message-ID: As has been mentioned earlier it is our intention to change the license of Erlang from the Erlang Public License (EPL) to the Apache 2.0 License (APL). For a smooth transition we need cooperation from all contributors to Erlang so that they can be released under the Apache 2.0 License beginning in the earliest possible coming release. A mail with the title "Erlang License Change: from EPL to APL 2.0" has now been sent out to all contributors. The contributor is asked to return the mail to us and by that confirming that they agree that their contribution can be licensed under Apache 2.0 License as well. The contributors are automatically collected from the official Git repository at GitHub. Earlier contributors might not receive this mail. In that case contact us. The Apache 2.0 License is well known and compliant with the Open Source Definition made by the Open Source Initiative (http://opensource.org). We believe that this change will enable an even wider use of Erlang. Regards Kenneth Lundin, Manager of the Erlang/OTP Team, Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Mar 24 01:45:34 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 24 Mar 2015 13:45:34 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <18777803.qjqNZhNtEs@moltowork> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> Message-ID: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> There is top posting where the quoted material has been carefully pruned to just the relevant bits. And there is top posting where the entire previous message has been included without thought, and I have to trawl carefully through it to see if I have missed some added material. I imagine it is that kind of post that has given top posting a bad name. "What is written without effort is in general read without pleasure." ? Samuel Johnson. From raould@REDACTED Tue Mar 24 01:48:20 2015 From: raould@REDACTED (Raoul Duke) Date: Mon, 23 Mar 2015 17:48:20 -0700 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> Message-ID: > I imagine it is that kind of > post that has given top posting a bad name. + lots, for pointing out an underlying usability distinction. I also do not mind top-posting as long as it isn't the pathalogically unthinkingly bad type. From zxq9@REDACTED Tue Mar 24 03:35:07 2015 From: zxq9@REDACTED (zxq9) Date: Tue, 24 Mar 2015 11:35:07 +0900 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> Message-ID: <1912794.FUqRW6ddgW@burrito> On Monday 23 March 2015 17:48:20 Raoul Duke wrote: > > And there is top posting where the entire previous > > message has been included without thought, and I have > > to trawl carefully through it to see if I have missed > > some added material. I imagine it is that kind of > > post that has given top posting a bad name. > > + lots, for pointing out an underlying usability distinction. > > I also do not mind top-posting as long as it isn't the pathalogically > unthinkingly bad type. [Expanded the quote for context] Finally, the problem. Its not that top posting or bottom posting or addressing points by interleaved quotation is always best -- it is that of all the forms, top posting is the one most commonly associated with thoughtless, effortless responses that are likely to waste the reader's time. In fact, top posting being the default for most mail clients is the very thing that makes me suspicious of top posts, because it is indeed effortless. It is likely anything quoted was only an inclusion incidental to thoughtless use of a mail agent, instead of something that required effort. In the few seconds it requires to place the cursor at the end of a message one has just a moment to reflect, to cool down, to visually recognize just how much irrelevant digital garbage one is about to bat right back at the mailing list server. This is a good thing. Perhaps we should embrace the idea that statements made in public places should be thoughtful and require some effort. This doesn't mean they must be dry, humorless, or even polite. One thing that has always stuck out to me about this relatively small but abnormally skilled community it is that it seems to place a very high value on quality. While this means different things to nearly everyone, "quality" and "thoughtless" tend to not go together. This is better expressed as an ethos than a rule set, and perhaps that is part of why there has been so much backlash in this thread. Some people clearly feel their expressive freedom is violated when asked to immediately comply with some unfamiliar CoC. -Craig From lloyd@REDACTED Tue Mar 24 05:24:44 2015 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 24 Mar 2015 00:24:44 -0400 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: Message-ID: <0F375108-344B-4DB9-A778-180A6D209447@writersglen.com> My great goodness me. I lost count after 100 replies to this post. Looks to be maybe twice as many? I've been monitoring and participating in this list for many moons now. I'm consistently impressed with the quality of content, civility of discussion, and patience of guru responses to dunderheaded noobie questions posted by folks like me. Code of conduct? Do we need one? Have I missed something? My contention: If we spent half as much intellectual horsepower working to polish obscure corners of Erlang libraries and docs as invested in this thread we'd have the finest language platform on the planet. But what do I know. All the best, LRP Sent from my iPad > On Mar 13, 2015, at 10:23 AM, Bruce Yinhe wrote: > > Hi everyone, > > To encourage a welcoming, inclusive climate for communication within the erlang.org community, the Erlang/OTP team, together with members of the community, has released a new code of conduct, available at http://www.erlang.org/download/erlang_org_code_of_conduct.txt. This code of conduct lays out a guideline of how to communicate within the erlang.org community in a way we hope is easy to read, help mutual understanding and avoid flames. The erlang.org community is by definition all communication in or around erlang.org, including but not limited to the erlang.org mailing lists or Github discussions. > > This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter. > > http://www.erlang.org/download/erlang_org_code_of_conduct.txt > > > -- > Bruce Yinhe > Erlang Community Manager > Industrial Erlang User Group > community-manager@REDACTED > +46 72 311 43 89 > _______________________________________________ > 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 Tue Mar 24 05:52:01 2015 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 23 Mar 2015 21:52:01 -0700 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <0F375108-344B-4DB9-A778-180A6D209447@writersglen.com> References: <0F375108-344B-4DB9-A778-180A6D209447@writersglen.com> Message-ID: I view discussion CoC to be a light diversion from discussing programming problems. A form of relaxation. Hearing my learned colleagues point of view on such matters is enlightening. If I had one rule it wouldn't be "be nice" it would be "try not to be boring" - but niceness and boringness are in the eye of the beholder ... /Joe On Mon, Mar 23, 2015 at 9:24 PM, Lloyd R. Prentice wrote: > My great goodness me. I lost count after 100 replies to this post. Looks to > be maybe twice as many? > > I've been monitoring and participating in this list for many moons now. I'm > consistently impressed with the quality of content, civility of discussion, > and patience of guru responses to dunderheaded noobie questions posted by > folks like me. > > Code of conduct? Do we need one? Have I missed something? > > My contention: If we spent half as much intellectual horsepower working to > polish obscure corners of Erlang libraries and docs as invested in this > thread we'd have the finest language platform on the planet. > > But what do I know. > > All the best, > > LRP > > Sent from my iPad > > On Mar 13, 2015, at 10:23 AM, Bruce Yinhe > wrote: > > Hi everyone, > > To encourage a welcoming, inclusive climate for communication within the > erlang.org community, the Erlang/OTP team, together with members of the > community, has released a new code of conduct, available at > http://www.erlang.org/download/erlang_org_code_of_conduct.txt. This code of > conduct lays out a guideline of how to communicate within the erlang.org > community in a way we hope is easy to read, help mutual understanding and > avoid flames. The erlang.org community is by definition all communication in > or around erlang.org, including but not limited to the erlang.org mailing > lists or Github discussions. > > This code is not exhaustive or complete. It serves to distill our common > understanding of a collaborative, shared environment and goals. We expect it > to be followed in spirit as much as in the letter. > > http://www.erlang.org/download/erlang_org_code_of_conduct.txt > > > -- > Bruce Yinhe > Erlang Community Manager > Industrial Erlang User Group > community-manager@REDACTED > +46 72 311 43 89 > > _______________________________________________ > 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 bengt.kleberg@REDACTED Tue Mar 24 07:12:25 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 24 Mar 2015 07:12:25 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <1505371.ZDRTPpM0Hs@moltowork> References: <18777803.qjqNZhNtEs@moltowork> <88861A65-20A3-40D2-992E-29ED75234BF9@pixie.co.za> <1505371.ZDRTPpM0Hs@moltowork> Message-ID: <55110049.1000407@ericsson.com> Greetings, I think that top posting is a good idea. It provides a complete context that can be perused if needed. Those that know the subject do not have to wade through many lines before they find the original content. bengt On 03/20/2015 03:34 PM, Vincent de Phily wrote: > On Friday 20 March 2015 15:09:45 Valentin Micic wrote: >>> The whole purpose of quoting (inline, top, partial, full, whatever) is to >>> provide context. I think we can all agree on that ? >> By just reading the above, I do not think you would be able to tell if the >> discussion was about top-posting vs in-line quoting, or we were just >> discussing about purpose quoting in general. > The two are not really separable : you do something for a purpose. My argument > is that on a mailing list, the only purpose of including (part of) the > original text in your reply is to provide context, and that this purpose isn't > served well by top-posting. > From bengt.kleberg@REDACTED Tue Mar 24 07:19:18 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 24 Mar 2015 07:19:18 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <17618904.xoVQttYHfG@moltowork> References: <18081302.eI0vuKfqsD@moltowork> <550A6E32.6080306@ericsson.com> <17618904.xoVQttYHfG@moltowork> Message-ID: <551101E6.1090209@ericsson.com> Greetings, While it is nice to see that fellow users of this mail-list think that I can do inline-quoting in 5 seconds it is not a correct number. For me to overcome my reluctance to edit another persons email would take much longer. The idea of checking for more content after a top post is perhaps something that those that inline quote think is a good idea. I never do, so I would not know. Please feel free to save that time. I hereby grant you permission, if that is what is needed. bengt On 03/20/2015 01:36 PM, Vincent de Phily wrote: > On Thursday 19 March 2015 07:35:30 Bengt Kleberg wrote: >> A top post with all the previous content below can save me time. It acts >> like a cache. I do not have to locate the right email in the archive if >> I want to check something. > I'm happy for you that you saved a precious 5 seconds not bothering with > inline-quoting (or 1 second if your mailer knows to only quote the highlighted > text when replying). > > I'm less happy that I had to spend 0.5 seconds double-checking the quoted part > to make sure there wasn't any actual content left (thankfully I trust that you > didn't misquote me, and didn't waste time checking that). If more than 10 > people have read your email and my statistics are somewhat correct, the > decision to top-post has caused a net time loss for the community. > > Please, if you don't have time for inline quoting, don't quote at all. If you > can't configure your mailer to do the right thing, hit "Ctrl-A Suppr" before > you start typing. > From bengt.kleberg@REDACTED Tue Mar 24 07:25:14 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 24 Mar 2015 07:25:14 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <18777803.qjqNZhNtEs@moltowork> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> Message-ID: <5511034A.8040508@ericsson.com> Greetings, To me there is a difference between manipulating the email of somebody else and leaving it intact. Top posting, and keeping things in an archive, both support the latter. Inline quoting insists upon the former. I do not like that manipulation so I do not do it. It is still possible to manipulate top post and archives. It is generally considered wrong, so I can relax when I see them. Not so with inline quotes. bengt On 03/20/2015 01:16 PM, Vincent de Phily wrote: > On Thursday 19 March 2015 07:58:22 Bengt Kleberg wrote: >> When advocating top posts as better than inline quotes, one reason >> mentioned is that it is possible to use inline quotes to manipulate the >> discussion whereas a top post will keep all quotes un-edited below. >> Sounds logical. > It isn't logical. Quotes can be edited and manipulated just as easily wether > they're partial or in full, inline or at the bottom. > > The only reason people are less afraid of manipulative editing in the toppost > case is that readers will likely not read the quoted text at all, and > therefore miss out on any manipulation. > > If you're afraid of manipulation, read the original, not the quote. That said, > if somebody intentionally misquotes to change the quoted text's meaning, it > calls for moderator action. > > >> The retort to this argument is that to prevent improper quotations no >> quotes should be allowed. >> I can not make the leap from, if keeping all text is better than editing >> it, then the really large edit of removing all text is even better. > The whole purpose of quoting (inline, top, partial, full, whatever) is to > provide context. I think we can all agree on that ? > > As it happens, on a mailing list (especially one with public archives), the > context of who you're replying to and the full original message is already > there. So including the whole original message in your reply doesn't add any > usefull context. Worse : it distracts the reader's attention and is therefore > worse than not quoting anything. > > On the other hand, inline quoting (part of) the original message adds useful > context. It pinpoints specific parts of the message that you're reacting to. > It makes email exchanges feel more like a natural discussion (where people > interrupt each other all the time) than if sending long essays back and forth. > > The community will collecively take more time reading your email than it took > you to write it. So Just like when writing maintainable code, it's worth > spending time to make your message as readable as possible. Inline quoting > helps, top posting doesn't. > > From schneider@REDACTED Tue Mar 24 10:09:29 2015 From: schneider@REDACTED (Frans Schneider) Date: Tue, 24 Mar 2015 10:09:29 +0100 Subject: [erlang-questions] Weird behaviuor of ei_x_free Message-ID: <551129C9.5090406@xs4all.nl> Hi list, While writing a simple port program in C, I ran in a problem with deallocating ei_x_buff results. After a few calls to the port, ei_x_new_with_version would crash with a malloc error. It turned out that when I replace the call ei_x_free(&result); with r = ei_x_free(&result); the problem is solved. This is what the code looks like: static void process_helo(const byte *_buf, int _index_start) { ei_x_buff result; ei_x_new_with_version(&result); ei_x_encode_atom(&result, "ok"); write_port_msg(result); ei_x_free(&result); } Could somebody explain what is going on here? Thanks, Frans Some details Erlang / OTP 17.4 from ESL gcc (Debian 4.7.2-5) 4.7.2 -g or -O3 flags have no differences Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux From essen@REDACTED Tue Mar 24 10:49:27 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 24 Mar 2015 10:49:27 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <1912794.FUqRW6ddgW@burrito> References: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <1912794.FUqRW6ddgW@burrito> Message-ID: <55113327.8010401@ninenines.eu> On 03/24/2015 03:35 AM, zxq9 wrote: > Its not that top posting or bottom posting or addressing points by interleaved > quotation is always best -- it is that of all the forms, top posting is the > one most commonly associated with thoughtless, effortless responses that are > likely to waste the reader's time. The funny thing about this is that your client wraps lines at exactly 80 characters, which makes all the last word of each line wraps on my screen and makes it much harder to read, wasting more time than top posting ever would. For example this is how your email looks like here: In fact, top posting being the default for most mail clients is the very thing that makes me suspicious of top posts, because it is indeed effortless. It is likely anything quoted was only an inclusion incidental to thoughtless use of a mail agent, instead of something that required effort. In the few seconds it requires to place the cursor at the end of a message one has just a moment to reflect, to cool down, to visually recognize just how much irrelevant digital garbage one is about to bat right back at the mailing list server. This is a good thing. I think this kind of issue, just like issues with top posting, are just an email client limitation and not a problem with the writer. Clients should make it easy for you to see that the rest of the email is just a quote just like they should not display only one or two words every two lines. Computers are there to solve our problems, not the other way around. -- Lo?c Hoguin http://ninenines.eu From tuncer.ayaz@REDACTED Tue Mar 24 12:20:01 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 24 Mar 2015 12:20:01 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> Message-ID: On Tue, Mar 24, 2015 at 1:45 AM, Richard A. O'Keefe wrote: > There is top posting where the quoted material > has been carefully pruned to just the relevant bits. > > And there is top posting where the entire previous > message has been included without thought, and I have > to trawl carefully through it to see if I have missed > some added material. I imagine it is that kind of > post that has given top posting a bad name. > > "What is written without effort is in general > read without pleasure." -- Samuel Johnson. I agree, but the least useful quoting that hasn't been mentioned yet is when someone responds to a previous message, but quotes nothing. This may be due to being used to bulletin board or forum systems with a universal client and, because email has no single unified client experience, it's up to the message author to do some editing/formatting that could mostly be handled by a computer. If the computer had the right kind of complete information to make unquestionably correct decisions, that could work, but current email clients differ in too many ways. To name one problem, there will always be that one email client ignoring In-Reply-To and breaking threading for everyone. From max.lapshin@REDACTED Tue Mar 24 12:21:39 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 24 Mar 2015 14:21:39 +0300 Subject: [erlang-questions] Strange problems with modifying records with matched maps on 17.4 Message-ID: https://gist.github.com/maxlapshin/a95d8a27ce93221d883a when I match map in record: modify(#r1{map_data = #{count := Cnt} = M}=R1) -> I get badarg when modify record in the end of function. I've attached two files looking similar in the gist. When I launch first, I get badarg with the line of function header: erl -s map_test1 main Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] Created: {r1,#{count => 1},0} {"init terminating in do_boot",{badarg,[{map_test1,modify,1,[{file,"map_test1.erl"},{line,11}]},{map_test1,main,0,[{file,"map_test1.erl"},{line,8}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} when I launch second, it works (but makes useless work). Is it a known bug? Or maybe it is not a bug, but just my misunderstanding? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergej.jurecko@REDACTED Tue Mar 24 12:25:57 2015 From: sergej.jurecko@REDACTED (=?UTF-8?Q?Sergej_Jure=C4=8Dko?=) Date: Tue, 24 Mar 2015 12:25:57 +0100 Subject: [erlang-questions] Strange problems with modifying records with matched maps on 17.4 In-Reply-To: References: Message-ID: Yes this is likely the same bug that I reported in february: http://erlang.org/pipermail/erlang-bugs/2015-February/004768.html Sergej On Tue, Mar 24, 2015 at 12:21 PM, Max Lapshin wrote: > https://gist.github.com/maxlapshin/a95d8a27ce93221d883a > > when I match map in record: > > modify(#r1{map_data = #{count := Cnt} = M}=R1) -> > > I get badarg when modify record in the end of function. > > I've attached two files looking similar in the gist. > > > > > When I launch first, I get badarg with the line of function header: > > erl -s map_test1 main > > Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] > [async-threads:10] [hipe] [kernel-poll:false] [dtrace] > > Created: {r1,#{count => 1},0} > > {"init terminating in > do_boot",{badarg,[{map_test1,modify,1,[{file,"map_test1.erl"},{line,11}]},{map_test1,main,0,[{file,"map_test1.erl"},{line,8}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} > > > when I launch second, it works (but makes useless work). > > > Is it a known bug? Or maybe it is not a bug, but just my misunderstanding? > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Tue Mar 24 12:38:16 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 24 Mar 2015 14:38:16 +0300 Subject: [erlang-questions] Strange problems with modifying records with matched maps on 17.4 In-Reply-To: References: Message-ID: Thanks On Tue, Mar 24, 2015 at 2:25 PM, Sergej Jure?ko wrote: > Yes this is likely the same bug that I reported in february: > http://erlang.org/pipermail/erlang-bugs/2015-February/004768.html > > > Sergej > > On Tue, Mar 24, 2015 at 12:21 PM, Max Lapshin > wrote: > >> https://gist.github.com/maxlapshin/a95d8a27ce93221d883a >> >> when I match map in record: >> >> modify(#r1{map_data = #{count := Cnt} = M}=R1) -> >> >> I get badarg when modify record in the end of function. >> >> I've attached two files looking similar in the gist. >> >> >> >> >> When I launch first, I get badarg with the line of function header: >> >> erl -s map_test1 main >> >> Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] >> [async-threads:10] [hipe] [kernel-poll:false] [dtrace] >> >> Created: {r1,#{count => 1},0} >> >> {"init terminating in >> do_boot",{badarg,[{map_test1,modify,1,[{file,"map_test1.erl"},{line,11}]},{map_test1,main,0,[{file,"map_test1.erl"},{line,8}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} >> >> >> when I launch second, it works (but makes useless work). >> >> >> Is it a known bug? Or maybe it is not a bug, but just my misunderstanding? >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Tue Mar 24 13:08:36 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 24 Mar 2015 13:08:36 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <0F375108-344B-4DB9-A778-180A6D209447@writersglen.com> Message-ID: On Tue, Mar 24, 2015 at 5:52 AM, Joe Armstrong wrote: > I view discussion CoC to be a light diversion from discussing > programming problems. A form of relaxation. > > Hearing my learned colleagues point of view on such matters is > enlightening. > > If I had one rule it wouldn't be "be nice" it would be "try not to > be boring" - but niceness and boringness are in the eye of the > beholder ... I hope we can refine things like that in the CoC to be more precise and less ambiguous. Writing the draft, we tried our best, but certain words may carry a different meaning given changing audiences. Also, a words's meanings will change over time, but that's what a timestamp is for. For example, we thought we made it clear that cursing/swearing is only acceptable if it's in a non-hateful manner directed at non-personal things, say, a piece of code. The idea was that one shouldn't go full emotional and curse at each other, while still allowing you to vent your frustration regarding a piece of code (or tech), if you *really have to*. However, text communication loses most of the nuances present in face to face conversations. That's why staying focused and avoiding formulations that are likely to be mis-interpreted given everyone's different backgrounds is a good idea, in terms of having a productive conversation. Writing "that function is ****" certainly conveys the point for most people, but you're highly likely to offend the author or somebody else, and in that process steer the conversation from technical facts to something based in emotions. That said, it's imortant to clearly state opinions, but there are many ways to do that which do not involve cursing/swearing. Actually, a statement like "this is ****" has to be followed by an explanation anyway, so formulating it as follows is more productive: "This looks wrong to me. Are you sure that....?" If explaining to someone that their code is completely wrong requires callig it names, as they would otherwise not understand the severity, there is a deeper communication problem, although it may sometimes be the only way. However, if somebody doesn't understand "it's completely wrong", I doubt they will have an easier time grasping "this is ****". Joe, returning to "be nice", I wasn't aware of the meaning this might have to somebody having grown up in a British household. In order to avoid that, maybe we should have used the long form "treat others as you desire to be treated" (or the "do not ..." version of it). I'm sorry about that, but it can be fixed. Just like writing code, it's almost always the best option to allocate more time to thinking about some statement you're about to make than trying out variations until one passes the crash test. In any situation, trial and error is seldom the right first action to take. From danrokk@REDACTED Tue Mar 24 13:57:07 2015 From: danrokk@REDACTED (Konrad Wyrozumski) Date: Tue, 24 Mar 2015 13:57:07 +0100 Subject: [erlang-questions] CT config Message-ID: Hi all, Some time ago I was working on some project and created Makefile that was running tests. Now it looks like something has changed with erlang release since R16 which is version I was working on. I want to specify config used for test suites and it seems like always Config gets values from ERL_OPTS, not CT_OPTS. Please see part of Makefile below: CT_OPTS= -stylesheet styles/test_categories.css -ct_config test.config -dir tests -logdir ct_report ERL_OPTS=-config app.config -sname $(DEBUG_NODE_NAME) -s lager -s chat_app -s chatest_app -s ct_run script_start -s erlang halt BEAMS_PATH=-pa ebin -pa ../chatd/ebin -pa ../chatd/deps/lager/ebin erl $(INCLUDES) $(BEAMS_PATH) $(ERL_OPTS) $(CT_OPTS) How can I specify config file that is passed to init_per_suite/1, end_per_suite/1 etc functions? Best Regards, -- Konrad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.widgren@REDACTED Tue Mar 24 15:03:46 2015 From: daniel.widgren@REDACTED (Daniel Hallin Widgren) Date: Tue, 24 Mar 2015 15:03:46 +0100 Subject: [erlang-questions] CT config In-Reply-To: References: Message-ID: Have you tried ct_run instead of erl? That will start common test from terminal. There is a section in user guide in common test documentation. Den 24 mar 2015 14:28 skrev "Konrad Wyrozumski" : > Hi all, > > Some time ago I was working on some project and created Makefile that was > running tests. Now it looks like something has changed with erlang release > since R16 which is version I was working on. > > I want to specify config used for test suites and it seems like always > Config gets values from ERL_OPTS, not CT_OPTS. Please see part of Makefile > below: > > CT_OPTS= -stylesheet styles/test_categories.css -ct_config test.config > -dir tests -logdir ct_report > ERL_OPTS=-config app.config -sname $(DEBUG_NODE_NAME) -s lager -s chat_app > -s chatest_app -s ct_run script_start -s erlang halt > BEAMS_PATH=-pa ebin -pa ../chatd/ebin -pa ../chatd/deps/lager/ebin > > erl $(INCLUDES) $(BEAMS_PATH) $(ERL_OPTS) $(CT_OPTS) > > How can I specify config file that is passed to init_per_suite/1, > end_per_suite/1 etc functions? > Best Regards, > > -- > Konrad. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocke@REDACTED Tue Mar 24 15:05:36 2015 From: jocke@REDACTED (Joakim G.) Date: Tue, 24 Mar 2015 15:05:36 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct Message-ID: <20150324140536.B500012809A8@mail.tail-f.com> Perhaps we could quote common moral values from holy books and put them in the CoC. For example, Matthew 7:12 and Luke 6:31. But wait, just a list of different and reused holy quotations could consitute the whole CoC. Reuse is common in software I have heard.Den 24 mar 2015 13:08 skrev Tuncer Ayaz : > > On Tue, Mar 24, 2015 at 5:52 AM, Joe Armstrong wrote: > > I view discussion CoC to be a light diversion from discussing > > programming problems. A form of relaxation. > > > > Hearing my learned colleagues point of view on such matters is > > enlightening. > > > > If I had one rule it wouldn't be "be nice" it would be "try not to > > be boring" - but niceness and boringness are in the eye of the > > beholder ... > > I hope we can refine things like that in the CoC to be more precise > and less ambiguous. Writing the draft, we tried our best, but certain > words may carry a different meaning given changing audiences. Also, a > words's meanings will change over time, but that's what a timestamp is > for. For example, we thought we made it clear that cursing/swearing is > only acceptable if it's in a non-hateful manner directed at > non-personal things, say, a piece of code. The idea was that one > shouldn't go full emotional and curse at each other, while still > allowing you to vent your frustration regarding a piece of code (or > tech), if you *really have to*. > > However, text communication loses most of the nuances present in face > to face conversations. That's why staying focused and avoiding > formulations that are likely to be mis-interpreted given everyone's > different backgrounds is a good idea, in terms of having a productive > conversation. Writing "that function is ****" certainly conveys the > point for most people, but you're highly likely to offend the author > or somebody else, and in that process steer the conversation from > technical facts to something based in emotions. That said, it's > imortant to clearly state opinions, but there are many ways to do that > which do not involve cursing/swearing. > > Actually, a statement like "this is ****" has to be followed by an > explanation anyway, so formulating it as follows is more productive: > > "This looks wrong to me. Are you sure that....?" > > If explaining to someone that their code is completely wrong requires > callig it names, as they would otherwise not understand the severity, > there is a deeper communication problem, although it may sometimes be > the only way. However, if somebody doesn't understand "it's completely > wrong", I doubt they will have an easier time grasping "this is ****". > > Joe, returning to "be nice", I wasn't aware of the meaning this might > have to somebody having grown up in a British household. In order to > avoid that, maybe we should have used the long form "treat others as > you desire to be treated" (or the "do not ..." version of it). I'm sorry > about that, but it can be fixed. > > Just like writing code, it's almost always the best option to allocate > more time to thinking about some statement you're about to make than > trying out variations until one passes the crash test. In any > situation, trial and error is seldom the right first action to take. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bchesneau@REDACTED Tue Mar 24 15:11:17 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 24 Mar 2015 15:11:17 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <0F375108-344B-4DB9-A778-180A6D209447@writersglen.com> Message-ID: On Tue, Mar 24, 2015 at 1:08 PM, Tuncer Ayaz wrote: > On Tue, Mar 24, 2015 at 5:52 AM, Joe Armstrong wrote: > > I view discussion CoC to be a light diversion from discussing > > programming problems. A form of relaxation. > > > > Hearing my learned colleagues point of view on such matters is > > enlightening. > > > > If I had one rule it wouldn't be "be nice" it would be "try not to > > be boring" - but niceness and boringness are in the eye of the > > beholder ... > > I hope we can refine things like that in the CoC to be more precise > and less ambiguous. Writing the draft, we tried our best, but certain > words may carry a different meaning given changing audiences. Also, a > words's meanings will change over time, but that's what a timestamp is > for. For example, we thought we made it clear that cursing/swearing is > only acceptable if it's in a non-hateful manner directed at > non-personal things, say, a piece of code. The idea was that one > shouldn't go full emotional and curse at each other, while still > allowing you to vent your frustration regarding a piece of code (or > tech), if you *really have to*. > > However, text communication loses most of the nuances present in face > to face conversations. That's why staying focused and avoiding > formulations that are likely to be mis-interpreted given everyone's > different backgrounds is a good idea, in terms of having a productive > conversation. Writing "that function is ****" certainly conveys the > point for most people, but you're highly likely to offend the author > or somebody else, and in that process steer the conversation from > technical facts to something based in emotions. That said, it's > imortant to clearly state opinions, but there are many ways to do that > which do not involve cursing/swearing. > > Actually, a statement like "this is ****" has to be followed by an > explanation anyway, so formulating it as follows is more productive: > > "This looks wrong to me. Are you sure that....?" > > If explaining to someone that their code is completely wrong requires > callig it names, as they would otherwise not understand the severity, > there is a deeper communication problem, although it may sometimes be > the only way. However, if somebody doesn't understand "it's completely > wrong", I doubt they will have an easier time grasping "this is ****". > > Joe, returning to "be nice", I wasn't aware of the meaning this might > have to somebody having grown up in a British household. In order to > avoid that, maybe we should have used the long form "treat others as > you desire to be treated" (or the "do not ..." version of it). I'm sorry > about that, but it can be fixed. > > Just like writing code, it's almost always the best option to allocate > more time to thinking about some statement you're about to make than > trying out variations until one passes the crash test. In any > situation, trial and error is seldom the right first action to take. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > I know a good "CoC" that most countries agreed to follow: http://www.un.org/en/documents/udhr/ Maybe a CoC (which is a private things) could be just summarised in agreeing to it. Rather than these conflicting, controversial and private things we see around.... - benoit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From e@REDACTED Tue Mar 24 15:11:50 2015 From: e@REDACTED (e@REDACTED) Date: Tue, 24 Mar 2015 15:11:50 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <20150324140536.B500012809A8@mail.tail-f.com> References: <20150324140536.B500012809A8@mail.tail-f.com> Message-ID: <551170A6.6090303@bestmx.net> On 03/24/2015 03:05 PM, Joakim G. wrote: > Perhaps we could quote common moral values from holy books and put them in the CoC. Perhaps we should institute a permanent ban for any non-sarcastic reference to religions? > For example, Matthew 7:12 and Luke 6:31. > > But wait, just a list of different and reused holy quotations could consitute the whole CoC. > > Reuse is common in software I have heard.Den 24 mar 2015 13:08 skrev Tuncer Ayaz : >> >> On Tue, Mar 24, 2015 at 5:52 AM, Joe Armstrong wrote: >>> I view discussion CoC to be a light diversion from discussing >>> programming problems. A form of relaxation. >>> >>> Hearing my learned colleagues point of view on such matters is >>> enlightening. >>> >>> If I had one rule it wouldn't be "be nice" it would be "try not to >>> be boring" - but niceness and boringness are in the eye of the >>> beholder ... >> >> I hope we can refine things like that in the CoC to be more precise >> and less ambiguous. Writing the draft, we tried our best, but certain >> words may carry a different meaning given changing audiences. Also, a >> words's meanings will change over time, but that's what a timestamp is >> for. For example, we thought we made it clear that cursing/swearing is >> only acceptable if it's in a non-hateful manner directed at >> non-personal things, say, a piece of code. The idea was that one >> shouldn't go full emotional and curse at each other, while still >> allowing you to vent your frustration regarding a piece of code (or >> tech), if you *really have to*. >> >> However, text communication loses most of the nuances present in face >> to face conversations. That's why staying focused and avoiding >> formulations that are likely to be mis-interpreted given everyone's >> different backgrounds is a good idea, in terms of having a productive >> conversation. Writing "that function is ****" certainly conveys the >> point for most people, but you're highly likely to offend the author >> or somebody else, and in that process steer the conversation from >> technical facts to something based in emotions. That said, it's >> imortant to clearly state opinions, but there are many ways to do that >> which do not involve cursing/swearing. >> >> Actually, a statement like "this is ****" has to be followed by an >> explanation anyway, so formulating it as follows is more productive: >> >> "This looks wrong to me. Are you sure that....?" >> >> If explaining to someone that their code is completely wrong requires >> callig it names, as they would otherwise not understand the severity, >> there is a deeper communication problem, although it may sometimes be >> the only way. However, if somebody doesn't understand "it's completely >> wrong", I doubt they will have an easier time grasping "this is ****". >> >> Joe, returning to "be nice", I wasn't aware of the meaning this might >> have to somebody having grown up in a British household. In order to >> avoid that, maybe we should have used the long form "treat others as >> you desire to be treated" (or the "do not ..." version of it). I'm sorry >> about that, but it can be fixed. >> >> Just like writing code, it's almost always the best option to allocate >> more time to thinking about some statement you're about to make than >> trying out variations until one passes the crash test. In any >> situation, trial and error is seldom the right first action to take. >> _______________________________________________ >> 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 e@REDACTED Tue Mar 24 15:16:19 2015 From: e@REDACTED (e@REDACTED) Date: Tue, 24 Mar 2015 15:16:19 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <55113327.8010401@ninenines.eu> References: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <1912794.FUqRW6ddgW@burrito> <55113327.8010401@ninenines.eu> Message-ID: <551171B3.4080109@bestmx.net> On 03/24/2015 10:49 AM, Lo?c Hoguin wrote: > On 03/24/2015 03:35 AM, zxq9 wrote: >> Its not that top posting or bottom posting or addressing points by >> interleaved >> quotation is always best -- it is that of all the forms, top posting >> is the >> one most commonly associated with thoughtless, effortless responses >> that are >> likely to waste the reader's time. > > The funny thing about this is that your client wraps lines at exactly 80 > characters, which makes all the last word of each line wraps on my > screen and makes it much harder to read, wasting more time than top > posting ever would. > > For example this is how your email looks like here: > > In fact, top posting being the default for most mail clients is the > very thing > that makes me suspicious of top posts, because it is indeed effortless. > It is > likely anything quoted was only an inclusion incidental to thoughtless > use of > I think this kind of issue, just like issues with top posting, are just > an email client limitation and not a problem with the writer. No. There is a big principal difference the issue above is a _technical_ issue. while top-posting is a _mental_ issue. Could you imagine zxq9 defending his mistake with formatting, making up philosophical arguments on why his formatting is sacred? From harit.subscriptions@REDACTED Tue Mar 24 15:37:33 2015 From: harit.subscriptions@REDACTED (Harit Himanshu) Date: Tue, 24 Mar 2015 07:37:33 -0700 Subject: [erlang-questions] Modeling Recursion into Tail Recursion In-Reply-To: References: <20150314165516.GA1159@arch.lan> Message-ID: Thank you so much for your valuable answers. On Sun, Mar 15, 2015 at 1:28 AM, wrote: > > On Sat, Mar 14, 2015 at 07:57:22AM -0700, Harit Himanshu wrote: > >> *Question* > >> 2. Can we turn every recursive function into tail-recursive? If no, > >> how > >> to identify? > > As for the second question I'm not 100% sure I'm remembering this > > correctly but using continuation-passing-style you could express every > > recursive function with tail-recursion. > > Yes you can but it's not USEFUL to do so. > Put very briefly, CPS style means passing an extra argument > to each function, called a "continuation". This is a function > that expresses "what to do next". > Basically, it *is* the recursion stack you would otherwise have > had, disguised as a function. > > There are plenty of good reasons to do this, such as situations > where a function needs more than one continuation, or you want to > simulate long-distance return, or you want a function that can > return more than once, e.g., to do backtracking. > > But using CPS in order to use tail recursion is like cutting > slots in nails so you can use a screwdriver on them. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Mar 24 18:09:16 2015 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 24 Mar 2015 18:09:16 +0100 Subject: [erlang-questions] Strange problems with modifying records with matched maps on 17.4 In-Reply-To: References: Message-ID: <55119A3C.5030805@erlang.org> On current maint + egil/fix-term-cmp/OTP-12623 (what jesper reported): egil/fix-term-cmp/OTP-12623 egil@REDACTED /ldisk/egil/git/otp/erts/emulator $ ../../bin/erl -s map_test1 main Erlang/OTP 17 [erts-6.3.1] [source-8c0c99b] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Created: {r1,#{count => 1},0} Modified: {r1,#{count => 2},0} Eshell V6.3.1 (abort with ^G) 1> Seems ok. // Bj?rn-Egil On 2015-03-24 12:38, Max Lapshin wrote: > Thanks > > On Tue, Mar 24, 2015 at 2:25 PM, Sergej Jure?ko > > wrote: > > Yes this is likely the same bug that I reported in february: > http://erlang.org/pipermail/erlang-bugs/2015-February/004768.html > > > Sergej > > On Tue, Mar 24, 2015 at 12:21 PM, Max Lapshin > > wrote: > > https://gist.github.com/maxlapshin/a95d8a27ce93221d883a > > when I match map in record: > > modify(#r1{map_data = #{count := Cnt} = M}=R1) -> > > I get badarg when modify record in the end of function. > > I've attached two files looking similar in the gist. > > > > > When I launch first, I get badarg with the line of function > header: > > erl -s map_test1 main > > Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] > [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace] > > Created: {r1,#{count => 1},0} > > {"init terminating in > do_boot",{badarg,[{map_test1,modify,1,[{file,"map_test1.erl"},{line,11}]},{map_test1,main,0,[{file,"map_test1.erl"},{line,8}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} > > > when I launch second, it works (but makes useless work). > > > Is it a known bug? Or maybe it is not a bug, but just my > misunderstanding? > > > > > _______________________________________________ > 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 e@REDACTED Tue Mar 24 18:34:24 2015 From: e@REDACTED (e@REDACTED) Date: Tue, 24 Mar 2015 18:34:24 +0100 Subject: [erlang-questions] Modeling Recursion into Tail Recursion In-Reply-To: References: <20150314165516.GA1159@arch.lan> Message-ID: <5511A020.4090602@bestmx.net> i think this question deserves a cheat-sheet for all times. something like: a quick overview of all sorts of recursion so, i am going to contribute a bit: >>> As for the second question I'm not 100% sure I'm remembering this >>> correctly but using continuation-passing-style you could express every >>> recursive function with tail-recursion. >> >> Yes you can but it's not USEFUL to do so. >> >> There are plenty of good reasons to do this, such as situations >> where a function needs more than one continuation, or you want to >> simulate long-distance return, or you want a function that can >> return more than once, e.g., to do backtracking. (1) continuation should not necessarily be represented as a whole function call, a subset of arguments might suffice. (2) i think that a good illustration for CPS is the tree-traversing. you can easily traverse tree in one order (following the edges of the tree at each recursive call), in this case each call will be complete upon traversing a respective sub-tree entirely. Which is not the only reasonable traversing order -- one might want to traverse "siblings-first". So, If you want to traverse through siblings before you go deeper in the tree, then CPS is the solution. regarding tail recursion: (3) it is not always useful. for example, your function projects a scalar to a list, foo: Int -> [Int] then the entire list will appear on the stack either way, with or without tail recursion. stack consumption of the "foo" is O(N) -- it is easier not to bother with tail recursion. From jesper.louis.andersen@REDACTED Tue Mar 24 21:42:13 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 24 Mar 2015 21:42:13 +0100 Subject: [erlang-questions] Strange problems with modifying records with matched maps on 17.4 In-Reply-To: <55119A3C.5030805@erlang.org> References: <55119A3C.5030805@erlang.org> Message-ID: Running 'master' of my maps_eqc test against that branch seems to work. I had to fix a problem with generation of function2/1 values[0], but now the model doesn't find any problem in release 17.4.1. [0] It would seem functions are seeded by self(), which is differing in my model. On Tue, Mar 24, 2015 at 6:09 PM, Bj?rn-Egil Dahlberg wrote: > On current maint + egil/fix-term-cmp/OTP-12623 (what jesper reported): > > egil/fix-term-cmp/OTP-12623 egil@REDACTED > /ldisk/egil/git/otp/erts/emulator $ ../../bin/erl -s map_test1 main > Erlang/OTP 17 [erts-6.3.1] [source-8c0c99b] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > Created: {r1,#{count => 1},0} > Modified: {r1,#{count => 2},0} > Eshell V6.3.1 (abort with ^G) > 1> > > Seems ok. > > // Bj?rn-Egil > > > On 2015-03-24 12:38, Max Lapshin wrote: > > Thanks > > On Tue, Mar 24, 2015 at 2:25 PM, Sergej Jure?ko > wrote: > >> Yes this is likely the same bug that I reported in february: >> http://erlang.org/pipermail/erlang-bugs/2015-February/004768.html >> >> >> Sergej >> >> On Tue, Mar 24, 2015 at 12:21 PM, Max Lapshin >> wrote: >> >>> https://gist.github.com/maxlapshin/a95d8a27ce93221d883a >>> >>> when I match map in record: >>> >>> modify(#r1{map_data = #{count := Cnt} = M}=R1) -> >>> >>> I get badarg when modify record in the end of function. >>> >>> I've attached two files looking similar in the gist. >>> >>> >>> >>> >>> When I launch first, I get badarg with the line of function header: >>> >>> erl -s map_test1 main >>> >>> Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] >>> [async-threads:10] [hipe] [kernel-poll:false] [dtrace] >>> >>> Created: {r1,#{count => 1},0} >>> >>> {"init terminating in >>> do_boot",{badarg,[{map_test1,modify,1,[{file,"map_test1.erl"},{line,11}]},{map_test1,main,0,[{file,"map_test1.erl"},{line,8}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} >>> >>> >>> when I launch second, it works (but makes useless work). >>> >>> >>> Is it a known bug? Or maybe it is not a bug, but just my >>> misunderstanding? >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > 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 24 22:48:36 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 25 Mar 2015 10:48:36 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <0F375108-344B-4DB9-A778-180A6D209447@writersglen.com> Message-ID: <7ED54E6D-B048-4E6D-82DE-5806BAE03168@cs.otago.ac.nz> On 24/03/2015, at 5:52 pm, Joe Armstrong wrote: > If I had one rule it wouldn't be "be nice" it would be "try not to be > boring" - but niceness and > boringness are in the eye of the beholder ... A case in point is "The Little Lisper", a book that teaches recursive programming very well, but to my taste is marred by an attempt at humour that I find clumsy and patronising. I don't think you know how to be boring, Joe. From danrokk@REDACTED Tue Mar 24 20:35:51 2015 From: danrokk@REDACTED (Konrad Wyrozumski) Date: Tue, 24 Mar 2015 20:35:51 +0100 Subject: [erlang-questions] CT config In-Reply-To: References: Message-ID: Hi, I tried that as well. Now the command that executes tests is like below: ct_run -pa ebin -pa ../ichatd/ebin -pa ../ichatd/deps/lager/ebin -sname ichatd_debug@REDACTED -s lager -s ichat_app -s chatest_app -s erlang halt -stylesheet styles/test_categories.css -ct_config test .config -dir tests -logdir ct_report So I removed app.config totaly from the command. I also checked with -config option, but the result stays the same. I printed the config that goes into test suite: [{chatest_cleaner,<0.456.0>}, {watchdog,<0.455.0>}, {tc_logfile, "c:/Users/Konrad/workspace/ichat/chatest/ct_report/ct_run.ichatd_debug@REDACTED /chatest.tests.logs/run.2015-03-24_20.34.00/room_suite.enter_story.html"}, {tc_group_properties,[{name,info},sequence]}, {tc_group_path,[]}, {data_dir, "c:/Users/Konrad/workspace/ichat/chatest/tests/room_SUITE_data/"}, {priv_dir, "c:/Users/Konrad/workspace/ichat/chatest/ct_report/ct_run.ichatd_debug@REDACTED /chatest.tests.logs/run.2015-03-24_20.34.00/log_private/"}] Do you have any other ideas? Best Regards, 2015-03-24 15:03 GMT+01:00 Daniel Hallin Widgren : > Have you tried ct_run instead of erl? > > That will start common test from terminal. > > There is a section in user guide in common test documentation. > Den 24 mar 2015 14:28 skrev "Konrad Wyrozumski" : > >> Hi all, >> >> Some time ago I was working on some project and created Makefile that was >> running tests. Now it looks like something has changed with erlang release >> since R16 which is version I was working on. >> >> I want to specify config used for test suites and it seems like always >> Config gets values from ERL_OPTS, not CT_OPTS. Please see part of Makefile >> below: >> >> CT_OPTS= -stylesheet styles/test_categories.css -ct_config test.config >> -dir tests -logdir ct_report >> ERL_OPTS=-config app.config -sname $(DEBUG_NODE_NAME) -s lager -s >> chat_app -s chatest_app -s ct_run script_start -s erlang halt >> BEAMS_PATH=-pa ebin -pa ../chatd/ebin -pa ../chatd/deps/lager/ebin >> >> erl $(INCLUDES) $(BEAMS_PATH) $(ERL_OPTS) $(CT_OPTS) >> >> How can I specify config file that is passed to init_per_suite/1, >> end_per_suite/1 etc functions? >> Best Regards, >> >> -- >> Konrad. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- Konrad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanssv@REDACTED Tue Mar 24 22:00:31 2015 From: hanssv@REDACTED (Hans Svensson) Date: Tue, 24 Mar 2015 22:00:31 +0100 Subject: [erlang-questions] Call For Papers: Erlang Workshop 2015 Message-ID: <5511D06F.2060302@gmail.com> Hello all, Please find below the Second Call for Papers for the Fourteenth ACM SIGPLAN Erlang Workshop. Apologies for any duplicates you may receive. CALL FOR PAPERS =============== Fourteenth ACM SIGPLAN Erlang Workshop ----------------------------------------------------------- Vancouver, Canada, September 4, 2015 Satellite event of the 20th ACM SIGPLAN International Conference on Functional Programming (ICFP 2015) August 30 - September 5, 2015 _http://www.erlang.org/workshop/2015/ErlangWorkshop2015.html_ 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 16 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 ------------------ Hans Svensson, QuviQ AB, Sweden Melinda T?th, E?tv?s Lor?nd University, Hungary Program Committee ----------------------------- (Note: the Workshop Co-Chairs are also committee members) Jesper L. Andersen, Independent Clara Benac Earle, Technical University of Madrid, Spain Laura M. Castro, University of A Coru?a, Spain Christopher Meiklejohn, Basho Technologies, Inc., US Samuel Rivas, Klarna AB, Sweden Tee Teoh, Erlang Solutions Ltd, UK Simon Thompson, University of Kent, UK Important Dates ----------------------- Submissions due: Friday, 22 May, 2015 Author notification: Friday, 26 June, 2015 Final copy due: Sunday, 19 July, 2015 Workshop date: September 4, 2015 Instructions to authors -------------------------------- Papers must be submitted online via EasyChair (via the "Erlang2015" event). The submission page is https://www.easychair.org/conferences/?conf=erlang2015 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. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. 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 2015 web site at: http://icfpconference.org/icfp2015/ Related Links -------------------- ICFP 2015 web site: http://www.icfpconference.org/icfp2015/ 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=erlang2015 Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Atendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/Anti-harassment -------------- next part -------------- An HTML attachment was scrubbed... URL: From jozsef.berces@REDACTED Wed Mar 25 05:05:08 2015 From: jozsef.berces@REDACTED (=?iso-8859-1?Q?J=F3zsef_B=E9rces?=) Date: Wed, 25 Mar 2015 04:05:08 +0000 Subject: [erlang-questions] Path to erl Message-ID: <7460EBDDCF52084A849D0F271CE059B809AEC041@ESESSMB101.ericsson.se> I think I have seen this recently somewhere I just do not find it. >From the Erlang VM, is it possible to get the full path of the Erlang executable that started the VM? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.youngkin@REDACTED Wed Mar 25 05:53:58 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Tue, 24 Mar 2015 21:53:58 -0700 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: <20150311232040.GA1523@ferdmbp.local> References: <20150311232040.GA1523@ferdmbp.local> Message-ID: Regarding how to ensure gen_server:terminate/2 is called... Maybe I'm being too pedantic (big word, sorry!), but the official documentation still confuses me. I created/ran several tests to better understand what actually is going on. LYSE says it best IMO, and using smaller words and shorter sentences (always good for me :>). My remaining comments are included in-line below. On Wed, Mar 11, 2015 at 4:20 PM, Fred Hebert wrote: > On 03/11, Youngkin, Rich wrote: > > "terminate/2 will also be called when its parent (the process that > spawned > > it) dies, if and only if the gen_server is trapping exits." > > > > [...] > > > > The Erlang documentation on Supervisors states "Note that all child > > processes implemented using the standard OTP behavior modules > automatically > > adhere to the shutdown protocol.". I'm having trouble reconciling these > > LYSE with the Erlang Supervisor docs. > The Erlang documentation on Supervisors leads me to believe that no special treatment is needed in order to for terminate/2 to be called, i.e., "...automatically adhere to the shutdown protocol". That said, I should have looked at the documentation on the "shutdown protocol". More below... > > > > Thanks, > > Rich > > The references I found to the shutdown protocol is: > > > http://www.erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html#shutdown > > "The supervisor process sends an exit signal to the child process and > waits for acknowledgment. The child process should handle the > {'EXIT',ParentPid,shutdown} message and terminate with reason shutdown > if it traps exit signals." > In my tests I didn't have to handle(_info) {'EXIT', ParentPid, shutdown). terminate/2 just gets called as a result of trapping exits when the supervisor directs the child to terminate (i.e., when the application is shutting down). So terminate/2 gets called, with reason "shutdown", not handle_info({'EXIT', ParentPid, shutdown}). But maybe... {'EXIT', ParentPid, shutdown} would be sent if the supervisor failed??? I didn't test that, but supervisors don't fail, right? > > The last line here is important -- if it traps exit signals. This is in > agreement with what LYSE mentions. If you don't trap exit signals, you > can't get the signal, it just kills the process directly. > WRT to trap exit, yes. WRT "The child process should handle the {'EXIT', ParentPid, shutdown} message...", no. > > Regards, > Fred. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Mar 25 06:33:42 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 24 Mar 2015 22:33:42 -0700 Subject: [erlang-questions] supervisors, gen_server:terminate/2, and trap_exit In-Reply-To: References: <20150311232040.GA1523@ferdmbp.local> Message-ID: <20150325053339.GB33506@ferdair.local> On 03/24, Youngkin, Rich wrote: >> "The supervisor process sends an exit signal to the child process and >> waits for acknowledgment. The child process should handle the >> {'EXIT',ParentPid,shutdown} message and terminate with reason shutdown >> if it traps exit signals." >> > >In my tests I didn't have to handle(_info) {'EXIT', ParentPid, shutdown). >terminate/2 just gets called as a result of trapping exits when the >supervisor directs the child to terminate (i.e., when the application is >shutting down). Yes, that is wht I meant. Sorry I was possibly not clear. The child process should handle that *automatically*. You won't see the signal yourself because the behaviours handles it. You will see other signals (from processes that are not your parent) in handle_info/2. >So terminate/2 gets called, with reason "shutdown", not >handle_info({'EXIT', ParentPid, shutdown}). But maybe... {'EXIT', >ParentPid, shutdown} would be sent if the supervisor failed??? I didn't >test that, but supervisors don't fail, right? > The message gets sent, but is caught by OTP for that specific one. Seehttps://github.com/erlang/otp/blob/maint/lib/stdlib/src/gen_server.erl#L380-L381 This however can only work when trapping exits. > >WRT to trap exit, yes. WRT "The child process should handle the {'EXIT', >ParentPid, shutdown} message...", no. > Yes. But it's just that the child process sees it handled by OTP. You, as an implementer of a gen_server or gen_fsm do not see it, but the child process *does* handle it. Sorry for the confusion. From bengt.kleberg@REDACTED Wed Mar 25 08:14:00 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 25 Mar 2015 08:14:00 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> Message-ID: <55126038.4050706@ericsson.com> Greetings, To me the good part with top posting is the knowledge that nobody is editing the quoted part. A top post where the quoted content is heavily edited is not better than inline comments. Again, to me. To trawl carefully through the quoted content in a top post message looking for added content is futile. If there is more content it is not a top post. Just the normal inline comment kind of email. There might be statistics that show how top posters write with less effort than inline commentors. That I have not heard of it does not prove anything. But I much prefer a effortless email that is helpful, to a carefully quote edited message where lots of effort has gone into being unhelpful and unpleasant. To be clear, the unedited quoted contents below are both helpful and pleasant. bengt On 03/24/2015 01:45 AM, Richard A. O'Keefe wrote: > There is top posting where the quoted material > has been carefully pruned to just the relevant bits. > > And there is top posting where the entire previous > message has been included without thought, and I have > to trawl carefully through it to see if I have missed > some added material. I imagine it is that kind of > post that has given top posting a bad name. > > "What is written without effort is in general > read without pleasure." ? Samuel Johnson. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dm.klionsky@REDACTED Wed Mar 25 10:08:32 2015 From: dm.klionsky@REDACTED (Dmitry Klionsky) Date: Wed, 25 Mar 2015 12:08:32 +0300 Subject: [erlang-questions] Path to erl In-Reply-To: <7460EBDDCF52084A849D0F271CE059B809AEC041@ESESSMB101.ericsson.se> References: <7460EBDDCF52084A849D0F271CE059B809AEC041@ESESSMB101.ericsson.se> Message-ID: <55127B10.6020309@gmail.com> Simple, but procfs specific: > file:read_link("/proc/" ++ os:getpid() ++ "/exe"). {ok,"/opt/r16b03-1/erts-5.10.4/bin/beam.smp"} On 03/25/2015 07:05 AM, J?zsef B?rces wrote: > > I think I have seen this recently somewhere I just do not find it. > > From the Erlang VM, is it possible to get the full path of the Erlang > executable that started the VM? > > Thanks > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergej.jurecko@REDACTED Wed Mar 25 10:14:48 2015 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Wed, 25 Mar 2015 10:14:48 +0100 Subject: [erlang-questions] Path to erl In-Reply-To: <55127B10.6020309@gmail.com> References: <7460EBDDCF52084A849D0F271CE059B809AEC041@ESESSMB101.ericsson.se> <55127B10.6020309@gmail.com> Message-ID: A platform independent way is: os:getenv(?BINDIR?)++?/erl? Sergej On 25 Mar 2015, at 10:08, Dmitry Klionsky wrote: > Simple, but procfs specific: > > > file:read_link("/proc/" ++ os:getpid() ++ "/exe"). > {ok,"/opt/r16b03-1/erts-5.10.4/bin/beam.smp"} > > > On 03/25/2015 07:05 AM, J?zsef B?rces wrote: >> I think I have seen this recently somewhere I just do not find it. >> >> From the Erlang VM, is it possible to get the full path of the Erlang executable that started the VM? >> >> 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 vincent.dephily@REDACTED Wed Mar 25 11:30:09 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Wed, 25 Mar 2015 11:30:09 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <55126038.4050706@ericsson.com> References: <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <55126038.4050706@ericsson.com> Message-ID: <3639185.YM5vy7WCBy@moltowork> TL;DR: repeating previous arguments, not sure how useful it is at this stage but hey. On Wednesday 25 March 2015 08:14:00 Bengt Kleberg wrote: > To me the good part with top posting is the knowledge that nobody is > editing the quoted part. A top post where the quoted content is heavily > edited is not better than inline comments. Again, to me. > > To trawl carefully through the quoted content in a top post message > looking for added content is futile. If there is more content it is not > a top post. Just the normal inline comment kind of email. This email has content above the quote as well as inline. How do you distinguish this case from the "top-post with pristine quote below" case ? Or did you not read past my first sentence (and therefore assume that I was accusing you of repetition instead of myself) ? The fact is that you never know what quoting convention has been used, so you always need to check through the whole thing. Hopefully your mailer gives a visual indication of what is a quote so that the check is very quick, but it still takes time. And if the post was the "include everything without touching it" kind, which provides no information that isn't already contained in the threading and the archives, this is wasted time. > There might be statistics that show how top posters write with less > effort than inline commentors. That I have not heard of it does not > prove anything. But I much prefer a effortless email that is helpful, to > a carefully quote edited message where lots of effort has gone into > being unhelpful and unpleasant. We all prefer helpfull messages. And the effort that has gone into writing a message hopefully correlates with the helpfullness of the message to the reader. Inline quoting accounts for a very small fraction of the message- writing effort, and is IMHO well worth the increased readability. > To be clear, the unedited quoted contents below are both helpful and > pleasant. Can't argue against subjectivity. To me, the contents below were completely useless, and therefore unpleasant. -- Vincent de Phily From sverker.eriksson@REDACTED Wed Mar 25 16:19:56 2015 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Wed, 25 Mar 2015 16:19:56 +0100 Subject: [erlang-questions] Weird behaviuor of ei_x_free In-Reply-To: <551129C9.5090406@xs4all.nl> References: <551129C9.5090406@xs4all.nl> Message-ID: <5512D21C.6050509@erix.ericsson.se> On 03/24/2015 10:09 AM, Frans Schneider wrote: > Hi list, > > While writing a simple port program in C, I ran in a problem with > deallocating ei_x_buff results. After a few calls to the port, > ei_x_new_with_version would crash with a malloc error. > It turned out that when I replace the call > > ei_x_free(&result); > > with > > r = ei_x_free(&result); > > the problem is solved. > This is what the code looks like: > > static void process_helo(const byte *_buf, int _index_start) { > ei_x_buff result; > > ei_x_new_with_version(&result); > ei_x_encode_atom(&result, "ok"); > write_port_msg(result); > ei_x_free(&result); > } > > Could somebody explain what is going on here? > I can try. Change your 'write_port_msg' function to take a *pointer" to ei_x_buff and change the call to pass a pointer to 'result': write_port_msg(&result). Your code passes 'result' by value and thereby gives write_port_msg a shallow copy of 'result'. /Sverker, Erlang/OTP From schneider@REDACTED Wed Mar 25 17:36:44 2015 From: schneider@REDACTED (Frans Schneider) Date: Wed, 25 Mar 2015 17:36:44 +0100 Subject: [erlang-questions] Weird behaviuor of ei_x_free In-Reply-To: <5512D21C.6050509@erix.ericsson.se> References: <551129C9.5090406@xs4all.nl> <5512D21C.6050509@erix.ericsson.se> Message-ID: <5512E41C.5010303@xs4all.nl> Works, Thanks. I made the assumption that since ei_x_buff already is a pointer, I could just pass it on. Thanks On 03/25/2015 04:19 PM, Sverker Eriksson wrote: > On 03/24/2015 10:09 AM, Frans Schneider wrote: >> Hi list, >> >> While writing a simple port program in C, I ran in a problem with >> deallocating ei_x_buff results. After a few calls to the port, >> ei_x_new_with_version would crash with a malloc error. >> It turned out that when I replace the call >> >> ei_x_free(&result); >> >> with >> >> r = ei_x_free(&result); >> >> the problem is solved. >> This is what the code looks like: >> >> static void process_helo(const byte *_buf, int _index_start) { >> ei_x_buff result; >> >> ei_x_new_with_version(&result); >> ei_x_encode_atom(&result, "ok"); >> write_port_msg(result); >> ei_x_free(&result); >> } >> >> Could somebody explain what is going on here? >> > I can try. > > Change your 'write_port_msg' function to take a *pointer" to ei_x_buff > and change the call to pass a pointer to 'result': > write_port_msg(&result). > > Your code passes 'result' by value and thereby gives write_port_msg a > shallow copy > of 'result'. > > /Sverker, Erlang/OTP > > From harit.subscriptions@REDACTED Wed Mar 25 19:46:22 2015 From: harit.subscriptions@REDACTED (Harit Himanshu) Date: Wed, 25 Mar 2015 11:46:22 -0700 Subject: [erlang-questions] Beginner Questions (Random) Message-ID: Hello there! I am erlang newbie (and functional programming newbie as well). I really like learning the language and functional paradigm. Few questions that pop up in my head are 1. Where can I learn more about functional programming while practicing them using Erlang? 2. I am following @joeerl book and its a fantastic read. But I am not at a stage to make applications using OTP, is it really worth spending time learning about OTP now as newbie? Any other words of wisdom you want to share Thanks + Harit Himanshu -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Wed Mar 25 20:05:30 2015 From: radek@REDACTED (Rad Gruchalski) Date: Wed, 25 Mar 2015 20:05:30 +0100 Subject: [erlang-questions] Beginner Questions (Random) In-Reply-To: References: Message-ID: Hi Harit, Regarding your second question. I had a number of attempts at Erlang and I was able to grasp how does it work and what problems it solves only by learning OTP first. I found ?Designing for Scalability with Erlang/OTP? extremely useful. Once I could write a fully functional (in terms of working) app using OTP, I could progress to understand how OTP itself works and thus learn all the necessary underlaying concepts (spawn, spawn_link, spawn_monitor, process and so on). OTP purifies everything what?s good in Erlang. I understand everybody has a different learning curve, just sharing my experience. Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Wednesday, 25 March 2015 at 19:46, Harit Himanshu wrote: > Hello there! > > I am erlang newbie (and functional programming newbie as well). I really like learning the language and functional paradigm. > > Few questions that pop up in my head are > Where can I learn more about functional programming while practicing them using Erlang? > I am following @joeerl book and its a fantastic read. But I am not at a stage to make applications using OTP, is it really worth spending time learning about OTP now as newbie? > > Any other words of wisdom you want to share > > Thanks > + Harit Himanshu > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From llbgurs@REDACTED Thu Mar 26 04:01:08 2015 From: llbgurs@REDACTED (linbo liao) Date: Thu, 26 Mar 2015 11:01:08 +0800 Subject: [erlang-questions] Multi processes consume limited redis resource Message-ID: Hi All, Here I meet a problem for client-server model when using Erlang OTP. Application will spawn multi processes, and each process will operate on limited redis resource, now it only have one redis instance. We wrapped redis client using poolboy , since producer processes are much more than redis pool size, checkout poolboy will failed, no more redis client in the pool. I think it is a common issue, when producer is faster than consumer, or producer are much more than consumer. Any common design or material for this issue? Thanks in advanced. Thanks, Linbo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Mar 26 04:07:03 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 26 Mar 2015 16:07:03 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <55126038.4050706@ericsson.com> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <55126038.4050706@ericsson.com> Message-ID: On 25/03/2015, at 8:14 pm, Bengt Kleberg wrote: > To me the good part with top posting is the knowledge that nobody is editing the quoted part. But how do you *get* that knowledge? The mere fact that something looks like a top posting is no guaranteed that the quoted material hasn't been edited. Nor do I believe that editing per se is in any way wrong or unhelpful. As long as quoted material is clearly quoted, and is not distorted, reducing it is *helpful*. It directs the reader's attention to the part(s) that the 2nd poster is actually responding to. > To trawl carefully through the quoted content in a top post message looking for added content is futile. If there is more content it is not a top post. Yes, but it's not as if top posts arrived in purple and inline annotation arrived in green. You can't be *sure* that a top post *is* a top post until you have looked. My memory may be deceiving me, but I believe I've seen several messages in this very list where I nearly missed some additional comment because it started out *looking* like a top post. > There might be statistics that show how top posters write with less effort than inline commentors. That I have not heard of it does not prove anything. But I much prefer a effortless email that is helpful, One of the arguments that has been made in this thread, and not as far as I know disputed, is that many people these days top-post without thinking about it because many modern MUAs make top-posting particularly easy. (For what it's worth, I am using Apple Mail version 7.3 (1878.6), released last year, and in-line annotation is perfectly straightforward. But I have inadequate knowledge of other modern MUAs to make general claims.) It is conceivable that such messages might be helpful; I have no statistics on this either. Only anecdotal evidence that I've seen top-posted messages in several mailing lists that their authors followed up with an "oops, sorry, I didn't fully read what I was responding to." I don't recall seeing such follow-ups for inline-annotated messages. That's just an impression from a memory that's like a sieve with holes in it. It would be interesting if someone with time on their hands investigated to see if top posted messages *were* noticeably helpful. And it's not as if it were the least bit *hard* to annotate in-line. To me, one issue is that in-line annotation provides evidence that the person writing the new comments has at least given every part of the message they are responding to a chance to pass by their eyeballs; they might just possibly have read it. There is also the helpfulness issue that each item of reply is right next to the thing it's a reply *to*; this makes it much easier for me to understand an inline-annotated message than a top-posted one. As I moderate no mailing list, my opinions have as much force as a politician's promise. But I shall continue to value inline-annotated messages more highly than top-posted ones. From petergi@REDACTED Thu Mar 26 02:53:49 2015 From: petergi@REDACTED (Peter J Etheridge) Date: Thu, 26 Mar 2015 12:53:49 +1100 Subject: [erlang-questions] The answer to Joe's question is...? Message-ID: dear list,on 19 march, Vol 209, Issue 7 Joe asked, to the effect;'is there a future-proof way of including the code of others' in mine?'this is a good question. i read the answers with interest.for the benefit of newcomers could someone please post a summary? many thanks,peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From kronic.deth@REDACTED Thu Mar 26 06:04:08 2015 From: kronic.deth@REDACTED (Luke Imhoff) Date: Wed, 25 Mar 2015 22:04:08 -0700 Subject: [erlang-questions] epmd/JInterface when vpn is active Message-ID: Whenever I turn on my work VPN, JInterface can no longer talk to an erlang node I'm running. Both nodes are on my laptop. I start the erlang node, `iex --sname intellij_elixir -S mix`, but the test times out, `did not receive message from Elixir.IntellijElixir.Quoter@REDACTED`. If I turn off the vpn, the connection works. I've tried killing epmd and making sure it starts once the VPN is active, in case it's binding to a different interface, but it still doesn't work until I kill the VPN. Is there anyway to debug what's happening with epmd or the message that JInterface can't deliver? -------------- next part -------------- An HTML attachment was scrubbed... URL: From harit.subscriptions@REDACTED Thu Mar 26 06:23:47 2015 From: harit.subscriptions@REDACTED (Harit Himanshu) Date: Wed, 25 Mar 2015 22:23:47 -0700 Subject: [erlang-questions] Learning from Open Source projects? Message-ID: Hello there! This is not exactly Erlang question, but since I am learning Erlang, I wanted to post this question here. Firstly, I am erlang newbie. I am reading book(s) and trying problems on Hackerrank I lose interest pretty quickly if I do not have project idea in my mind. So as I started searching, I get ideas like http://stackoverflow.com/questions/1282205/what-are-the-best-open-source-erlang-projects-files-for-a-novice-to-read http://stackoverflow.com/questions/1451278/best-open-source-projects-in-erlang-otp-for-learning Which brings an interesting point to me. I do like to read code. But what's the strategy? So questions are 1. How do you read/learn open-source library? 2. What techniques do you use to make sure you understand it correctly? 3. What Erlang projects (specifically) would you recommend a beginner to take a look, read and contribute Please share your ideas Thank you + Harit -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane@REDACTED Thu Mar 26 06:26:34 2015 From: stephane@REDACTED (=?utf-8?q?St=C3=A9phane?= Wirtel) Date: Thu, 26 Mar 2015 06:26:34 +0100 Subject: [erlang-questions] Learning from Open Source projects? In-Reply-To: References: Message-ID: <9BA16ACB-CD30-4506-89C0-2BE64A068C99@wirtel.be> On 26 Mar 2015, at 6:23, Harit Himanshu wrote: > Hello there! > > This is not exactly Erlang question, but since I am learning Erlang, I > wanted to post this question here. > > Firstly, I am erlang newbie. > I am reading book(s) and trying problems on Hackerrank > > I lose interest pretty quickly if I do not have project idea in my > mind. So > as I started searching, I get ideas like > > http://stackoverflow.com/questions/1282205/what-are-the-best-open-source-erlang-projects-files-for-a-novice-to-read > http://stackoverflow.com/questions/1451278/best-open-source-projects-in-erlang-otp-for-learning > > Which brings an interesting point to me. I do like to read code. But > what's > the strategy? > > So questions are > > 1. How do you read/learn open-source library? Cowboy, Ranch, Hackney if you want to read the code of HTTP server/client > 2. What techniques do you use to make sure you understand it > correctly? Just read, and try to understand, take a paper and write on it. > 3. What Erlang projects (specifically) would you recommend a beginner > to > take a look, read and contribute on the github site, you have the search feature, just type "language: elixir" in the search bar. -- St?phane Wirtel - http://wirtel.be - @matrixise From zxq9@REDACTED Thu Mar 26 06:58:01 2015 From: zxq9@REDACTED (zxq9) Date: Thu, 26 Mar 2015 14:58:01 +0900 Subject: [erlang-questions] epmd/JInterface when vpn is active In-Reply-To: References: Message-ID: <2511399.OKQ0LDWM6X@changa> On 2015?3?25? ??? 22:04:08 Luke Imhoff wrote: > Whenever I turn on my work VPN, JInterface can no longer talk to an erlang > node I'm running. Both nodes are on my laptop. > > I start the erlang node, `iex --sname intellij_elixir -S mix`, but the test > times out, `did not receive message from > Elixir.IntellijElixir.Quoter@REDACTED`. If I turn off the vpn, the > connection works. I've tried killing epmd and making sure it starts once > the VPN is active, in case it's binding to a different interface, but it > still doesn't work until I kill the VPN. Whenever someone says "doesn't work with VPN turned on" I immediately suspect a DNS resolution failure, a routing problem, or both. Nearly all VPN utilities will require both alterations to your packet routing (hopefully just within the VPNs range, but a lot of them default to just crushing your routing tables and making EVERYTHING run through the VPN), and to take over DNS resolution (once again, this is best when its configured to only resolve whatever is in the private network, but I nearly always see them configured to just take over ALL DNS resolution). "intellij_elixir" is something you might want to try throwing in /etc/hosts, or specifying localhost as the name or whatever. In any case, this is the direction I would look first. From me@REDACTED Thu Mar 26 07:45:03 2015 From: me@REDACTED (Leandro Ostera) Date: Thu, 26 Mar 2015 03:45:03 -0300 Subject: [erlang-questions] Learning from Open Source projects? In-Reply-To: <9BA16ACB-CD30-4506-89C0-2BE64A068C99@wirtel.be> References: <9BA16ACB-CD30-4506-89C0-2BE64A068C99@wirtel.be> Message-ID: Hi Harit! And welcome, I'm in the same quest myself. What I did was start a project that I'd already know how to build with another set of technologies (think RESTlike API on Express/Rails/Flask) and then look for a way to build it with Erlang. Think "backend for To-do app" in Erlang. That immediately narrows it down to the particular implementation of the protocols you already know. In my case, HTTP, so finding Cowboy, Nitrogen, mochiweb, and webmachine, wasn't really that hard. I picked webmachine and I'm just building stuff with it now, and that led to building some other OTP specific things like a port for streaming data into erlang (which is still in the makings). Hope it helps On Thu, Mar 26, 2015 at 2:26 AM, St?phane Wirtel wrote: > On 26 Mar 2015, at 6:23, Harit Himanshu wrote: > > Hello there! >> >> This is not exactly Erlang question, but since I am learning Erlang, I >> wanted to post this question here. >> >> Firstly, I am erlang newbie. >> I am reading book(s) and trying problems on Hackerrank >> >> I lose interest pretty quickly if I do not have project idea in my mind. >> So >> as I started searching, I get ideas like >> >> http://stackoverflow.com/questions/1282205/what-are- >> the-best-open-source-erlang-projects-files-for-a-novice-to-read >> http://stackoverflow.com/questions/1451278/best-open- >> source-projects-in-erlang-otp-for-learning >> >> Which brings an interesting point to me. I do like to read code. But >> what's >> the strategy? >> >> So questions are >> >> 1. How do you read/learn open-source library? >> > Cowboy, Ranch, Hackney if you want to read the code of HTTP server/client > > 2. What techniques do you use to make sure you understand it correctly? >> > Just read, and try to understand, take a paper and write on it. > > 3. What Erlang projects (specifically) would you recommend a beginner to >> take a look, read and contribute >> > on the github site, you have the search feature, just type "language: > elixir" in the search bar. > > > -- > St?phane Wirtel - http://wirtel.be - @matrixise > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Leandro Ostera Github | LinkedIn | Facebook | @leostera -------------- next part -------------- An HTML attachment was scrubbed... URL: From prehistorya@REDACTED Thu Mar 26 09:18:50 2015 From: prehistorya@REDACTED (Halil Ibrahim YILMAZ) Date: Thu, 26 Mar 2015 10:18:50 +0200 Subject: [erlang-questions] Erlang Phash Integration Message-ID: Hi guys, I?m looking for Erlang Phash integrated (http://phash.org ) open source projects. I?ve already searched in Github. Actually, I?m working on a project that targeting to find similar images. The media files are stored on the filesystem. I use Riak in the database layer. I?ve thought that storing the files in a Riak bucket as binary for using map-reduce (via javascript) to make ?phash" operations. BTW, there are some files that bigger than 50MB. Any other suggestions are welcome. P.S: I?m a newbie Erlanger :)= Cheers, Ibrahim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.dephily@REDACTED Thu Mar 26 11:50:51 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Thu, 26 Mar 2015 11:50:51 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <55126038.4050706@ericsson.com> Message-ID: <1759336.jlCHC02v9p@moltowork> On Thursday 26 March 2015 16:07:03 Richard A. O'Keefe wrote: > As I moderate no mailing list, my opinions have as much > force as a politician's promise. But I shall continue > to value inline-annotated messages more highly than > top-posted ones. It's like going to a job interview badly dressed, punctuating your everyday language with swear words, or leaving lots of grammar/spelling errors in your texts. Some people you speak to won't mind, care, or notice. But many people will notice, and the majority of those will not tell you about it : they'll just tend to disregard you in more or less subtle ways. In the end, it's your problem more than their's. Top-posting is the spelling mistake of mailing lists. Some readers won't care, and some will find the message annoying and/or harder to understand. If they do, it's the top-poster's loss. -- Vincent de Phily From essen@REDACTED Thu Mar 26 12:09:12 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 26 Mar 2015 12:09:12 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <1759336.jlCHC02v9p@moltowork> References: <55126038.4050706@ericsson.com> <1759336.jlCHC02v9p@moltowork> Message-ID: <5513E8D8.8010308@ninenines.eu> On 03/26/2015 11:50 AM, Vincent de Phily wrote: > On Thursday 26 March 2015 16:07:03 Richard A. O'Keefe wrote: >> As I moderate no mailing list, my opinions have as much >> force as a politician's promise. But I shall continue >> to value inline-annotated messages more highly than >> top-posted ones. > > It's like going to a job interview badly dressed, punctuating your everyday > language with swear words, or leaving lots of grammar/spelling errors in your > texts. Some people you speak to won't mind, care, or notice. But many people > will notice, and the majority of those will not tell you about it : they'll > just tend to disregard you in more or less subtle ways. In the end, it's your > problem more than their's. > > Top-posting is the spelling mistake of mailing lists. Some readers won't care, > and some will find the message annoying and/or harder to understand. If they > do, it's the top-poster's loss. You say this but you have the same problem as zxq9. In my client your "properly formatted email" has line breaks about every 80 characters, which results in every second line being exactly one word. It wouldn't be like this if you or your client didn't put those line breaks. It's interesting because you say the writer has to format his email keeping in mind how people will read it, in an email that is actually much harder to read for me than top posting. Considering the very large number of clients and possible configurations, I find it very odd to blame the one writing the email instead of the client being used to read said email. An email isn't a PDF, it *will* display differently everywhere. Should I, as an email writer, be careful about using the ')' character just because many clients will convert it to a smiley? Though I'm guessing your answer there is "no because my client doesn't do it and my client is right and all others are wrong". It is trivial to detect the rest of an email is just a quote and the client should indicate that (it would also be useful for those who do quote inline but leave a large quote unanswered at the end), just like it should be trivial for my client to change the flow of text to make it readable instead of the mess it makes right now. I find it fascinating that the code of conduct has only had the opposite of the intended effect so far. -- Lo?c Hoguin http://ninenines.eu From zxq9@REDACTED Thu Mar 26 12:32:09 2015 From: zxq9@REDACTED (zxq9) Date: Thu, 26 Mar 2015 20:32:09 +0900 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5513E8D8.8010308@ninenines.eu> References: <1759336.jlCHC02v9p@moltowork> <5513E8D8.8010308@ninenines.eu> Message-ID: <12419186.x3nkjg4URi@changa> On 2015?3?26? ??? 12:09:12 Lo?c Hoguin wrote: > On 03/26/2015 11:50 AM, Vincent de Phily wrote: > > On Thursday 26 March 2015 16:07:03 Richard A. O'Keefe wrote: > >> As I moderate no mailing list, my opinions have as much > >> force as a politician's promise. But I shall continue > >> to value inline-annotated messages more highly than > >> top-posted ones. > > > > It's like going to a job interview badly dressed, punctuating your > > everyday > > language with swear words, or leaving lots of grammar/spelling errors in > > your texts. Some people you speak to won't mind, care, or notice. But > > many people will notice, and the majority of those will not tell you > > about it : they'll just tend to disregard you in more or less subtle > > ways. In the end, it's your problem more than their's. > > > > Top-posting is the spelling mistake of mailing lists. Some readers won't > > care, and some will find the message annoying and/or harder to > > understand. If they do, it's the top-poster's loss. > > You say this but you have the same problem as zxq9. In my client your > "properly formatted email" has line breaks about every 80 characters, > which results in every second line being exactly one word. It wouldn't > be like this if you or your client didn't put those line breaks. Order of lines != Length of lines. Perhaps you have missed this detail. I variously use Kmail, Thunderbird, whatever client AU provides on one phone, whatever (different) client Willcom provides on another, Mutt, and a web interface I don't know the name of. Mail displays very differently in each save one point: they all display the lines in order. While I am not about to run around figuring out how to set all my clients on all my devices to format messages for *just* this one list in a way that either inserts newlines only when I hit or cuts them exactly at 74 characters, I am concerned that the continuity of what I write and what I read makes sense. > It is trivial to detect the rest of an email is just a quote and the > client should indicate that (it would also be useful for those who do > quote inline but leave a large quote unanswered at the end), just like > it should be trivial for my client to change the flow of text to make it > readable instead of the mess it makes right now. No, there is a semantic ambiguity here -- until you use your wizardly powers to write a mail client that can not only display your mail, but can also interpret what its author intended you see. Gmail makes an attempt to roll-up quotations in a way that tries to make email exchanges "conversations" instead of a series of essentially on-off messages (and Kmail can be made to behave this way), but this feature tends to confound the very best examples of point- for-point discussion I see on lists, be turned off by the user, or only work well on Outlook-style top-posted messages. > I find it fascinating that the code of conduct has only had the opposite > of the intended effect so far. I, too, find this rather interesting. It would be nice if we could go back to discussing that one thing... what was it... Oh yes, Erlang. From essen@REDACTED Thu Mar 26 12:48:53 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 26 Mar 2015 12:48:53 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <12419186.x3nkjg4URi@changa> References: <1759336.jlCHC02v9p@moltowork> <5513E8D8.8010308@ninenines.eu> <12419186.x3nkjg4URi@changa> Message-ID: <5513F225.7010806@ninenines.eu> On 03/26/2015 12:32 PM, zxq9 wrote: > No, there is a semantic ambiguity here -- until you use your wizardly powers > to write a mail client that can not only display your mail, but can also > interpret what its author intended you see. I want my email client to display emails the way *I* want to read them, not the way *you* want me to see them. The former case is doable, the latter case impossible with the variety of devices and configurations. So there is absolutely no need to interpret what the author wanted me to see. All I need is more options in my client. Of course if what your goal is the latter case then you don't have much choice other than restrict everyone to a specific set of rules and software, cutting yourself from the practices of the rest of the world. Good luck with that. I'll leave it at that, we just have different views on how emails should be consumed. Cheers, -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Thu Mar 26 13:41:20 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 26 Mar 2015 13:41:20 +0100 Subject: [erlang-questions] Learning from Open Source projects? In-Reply-To: References: <9BA16ACB-CD30-4506-89C0-2BE64A068C99@wirtel.be> Message-ID: On Thu, Mar 26, 2015 at 7:45 AM, Leandro Ostera wrote: > What I did was start a project that I'd already know how > to build with another set of technologies (think RESTlike > API on Express/Rails/Flask) and then look for a way to > build it with Erlang. Think "backend for To-do app" in Erlang. > I agree with this. When learning a new technology, try to retain as much knowledge you have from other technologies, so you don't need a grand leap of faith or a hail-mary pass. Erlang often challenges newcomers in several ways: * functional programming in a mostly-pure environment * distributed computing * concurrency * error handling through asynchronous monitors/links * language syntax and semantics * how to build large erlang systems: module composition, releases, configuration, deployment * how to test Erlang programs which have the above distribution/concurrency traits * learning the performance model of Erlang: what is fast, what is slow * all of the OTP stack, its idioms, design choices and how it influences program architecture If most of these are new to you, then you don't want to throw in a complicated problem you don't know as well. At least not until you have some proficiency in the above. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.wycisk@REDACTED Thu Mar 26 14:42:42 2015 From: p.wycisk@REDACTED (=?UTF-8?Q?Przemys=C5=82aw_Wycisk?=) Date: Thu, 26 Mar 2015 14:42:42 +0100 Subject: [erlang-questions] distributed erlang machine crash problem Message-ID: Consider n machines(servers), and one erlang node on each machine with application X started. In case when one machine crashes, we would want its X application to be restarted on another machine (for example on separate erl process on one of n-1 remaining machines). The problem is that we need cache from crashed node to restart it in its before (machine)crash state, we don't want to lose any "fly" data. We have two ideas how to solve that problem: - write an application (lets call it Y), which can store all needed data to restart a X application, there could be several instances of Y on several machines, which will have to be up to date with X application's state to restart it without lose of data, - keep exact mirror of X application on several machines, only one responsive, other only for keeping processes, and state data. Mirrors would just create mirror processes and update its state up to master X application. On master X application crash, one of mirrors would just "unlock" and run as master. In my opinion second idea is worse than first, because that requires all operations to be executed twice or triply or etc. (on master and others instances) and could bring huge performance loss, but renewal would work immediately. First idea seems good, but question is how fast restart could be then, we don't have experience with solution like that. What do you think about both solutions? Are there any proven solutions to solve that problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.dephily@REDACTED Thu Mar 26 15:14:29 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Thu, 26 Mar 2015 15:14:29 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5513E8D8.8010308@ninenines.eu> References: <1759336.jlCHC02v9p@moltowork> <5513E8D8.8010308@ninenines.eu> Message-ID: <5129072.byzI9vbLKs@moltowork> On Thursday 26 March 2015 12:09:12 Lo?c Hoguin wrote: > You say this but you have the same problem as zxq9. In my client your > "properly formatted email" has line breaks about every 80 characters, > which results in every second line being exactly one word. It wouldn't > be like this if you or your client didn't put those line breaks. > > It's interesting because you say the writer has to format his email > keeping in mind how people will read it, in an email that is actually > much harder to read for me than top posting. I'm sorry to hear that. I was aware of clients that couldn't display more than 80 chars, but it seems yours has a lower limit. The cut at 78 chars is indeed my MTU's doing. Having every second line consisting of just one word is your MTU's doing. See the archives : http://erlang.org/pipermail/erlang-questions/2015-March/084025.html I find such a receiver-side display limit anachronistic, but it seems that it can't be helped, so here's a mail reconfigured to cut at 74 chars for your viewing pleasure. I'm on record saying that 74 chars is a silly limit, and I'd prefer if word-wraping was only done at display time, but plaintext being what it is, wraping must still be done at writing time in some cases (for example when indenting bullet points). Html emails may be a solution, but they're a horrible one. So we still have to deal with write-time wraping at a lowest common denominator cutoff point. Thanks for reminding me that 78 chars was still too wide; are you sure you can't upgrade ? :p > Considering the very large number of clients and possible > configurations, I find it very odd to blame the one writing the email > instead of the client being used to read said email. There. I blamed your mail reader for pointlessly wraping my conservatively-sized lines. Sometimes it's the writer's MTU, sometimes the reader's, sometimes the MTA, sometimes the human... Let's deal with each separately. > An email isn't a PDF, it *will* display differently everywhere. Yes, I've mentioned that issue above. > Should I, as an email writer, be careful about using the ')' character > just because many clients will convert it to a smiley? You should, on any medium, be aware of your reader's general limitations. That doesn't mean that you absolutely must deal with every silly case. Accidental smileys are frequent enough, especially with computer code, so I hope that the reader has a way to turn them on and off. Like it should have a way to temporally use monospaced fonts when someone sends an ascii diagram. > Though I'm guessing your answer there is "no because my client doesn't > do it and my client is right and all others are wrong". I hope I don't sound that obnoxious ? > It is trivial to detect the rest of an email is just a quote and the > client should indicate that (it would also be useful for those who do > quote inline but leave a large quote unanswered at the end), All MTUs I know display quotes a bit differently, sometimes even collapsing them by default. That makes parsing them easy for the user (though there's still that gmail bug that puts the first line of the reply inside the quote...), but it's still be nice to avoid having to parse the quote if the quote wasn't necessary to begin with. > just like it should be trivial for my client to change the flow of text > to make it readable instead of the mess it makes right now. My client (kmail) happens to help with that by re-adding the proper quote markers when I hit enter inside a quote, but I'd say that the general case is not trivial. The only MTU that I remember being good at that is gnus (an emacs mode), most other MTUs I've seen don't help at all. > I find it fascinating that the code of conduct has only had the opposite > of the intended effect so far. The paragraphs about style have been removed from the CoC, so this thread is not really about CoC anymore. And as much as I dislike top posting, it's a trivial issue compared to verbal abuse. -- Vincent de Phily From harit.subscriptions@REDACTED Thu Mar 26 15:45:30 2015 From: harit.subscriptions@REDACTED (Harit Himanshu) Date: Thu, 26 Mar 2015 07:45:30 -0700 Subject: [erlang-questions] Learning from Open Source projects? In-Reply-To: References: <9BA16ACB-CD30-4506-89C0-2BE64A068C99@wirtel.be> Message-ID: very interesting points. Thank you very much + Harit Himanshu On Thu, Mar 26, 2015 at 5:41 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Thu, Mar 26, 2015 at 7:45 AM, Leandro Ostera wrote: > >> What I did was start a project that I'd already know how >> to build with another set of technologies (think RESTlike >> API on Express/Rails/Flask) and then look for a way to >> build it with Erlang. Think "backend for To-do app" in Erlang. >> > > I agree with this. When learning a new technology, try to retain as much > knowledge you have from other technologies, so you don't need a grand leap > of faith or a hail-mary pass. > > Erlang often challenges newcomers in several ways: > > * functional programming in a mostly-pure environment > * distributed computing > * concurrency > * error handling through asynchronous monitors/links > * language syntax and semantics > * how to build large erlang systems: module composition, releases, > configuration, deployment > * how to test Erlang programs which have the above > distribution/concurrency traits > * learning the performance model of Erlang: what is fast, what is slow > * all of the OTP stack, its idioms, design choices and how it influences > program architecture > > If most of these are new to you, then you don't want to throw in a > complicated problem you don't know as well. At least not until you have > some proficiency in the above. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Mar 26 16:24:13 2015 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 26 Mar 2015 15:24:13 +0000 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5129072.byzI9vbLKs@moltowork> References: <1759336.jlCHC02v9p@moltowork> <5513E8D8.8010308@ninenines.eu> <5129072.byzI9vbLKs@moltowork> Message-ID: These discussions about top posting (which is the default in most mua now) seem quite frivolous... Top posting is about providing an *over*view , what generally follows is the context of this overview (ie the previous mail). Some are also attaching this context. Bottom posting is about answering to a context. Some prefer to answer inline. Some are mixing top posting and inline content to provide a more accurate message (ie. giving an overview and answering in detail) See all of these methods answers to different types of communications. Imposing one over the other is a nonsense imo... As for the 80 chars limit in mail I stopped since a long time to have it, since i had to do it manually and like Loic and others noticed it provides different results depending on the machine or mua. Anyway we can have long debate about it but it seems weird to have it in a thread about a CoC which goals is to welcome others. - benoit On Thu, Mar 26, 2015 at 7:14 AM Vincent de Phily < vincent.dephily@REDACTED> wrote: > On Thursday 26 March 2015 12:09:12 Lo?c Hoguin wrote: > > You say this but you have the same problem as zxq9. In my client your > > "properly formatted email" has line breaks about every 80 characters, > > which results in every second line being exactly one word. It wouldn't > > be like this if you or your client didn't put those line breaks. > > > > It's interesting because you say the writer has to format his email > > keeping in mind how people will read it, in an email that is actually > > much harder to read for me than top posting. > > I'm sorry to hear that. I was aware of clients that couldn't display more > than 80 chars, but it seems yours has a lower limit. > > The cut at 78 chars is indeed my MTU's doing. Having every second line > consisting of just one word is your MTU's doing. See the archives : > http://erlang.org/pipermail/erlang-questions/2015-March/084025.html > > I find such a receiver-side display limit anachronistic, but it seems that > it can't be helped, so here's a mail reconfigured to cut at 74 chars for > your viewing pleasure. > > I'm on record saying that 74 chars is a silly limit, and I'd prefer if > word-wraping was only done at display time, but plaintext being what it > is, wraping must still be done at writing time in some cases (for example > when indenting bullet points). Html emails may be a solution, but they're > a horrible one. > > So we still have to deal with write-time wraping at a lowest common > denominator cutoff point. Thanks for reminding me that 78 chars was still > too wide; are you sure you can't upgrade ? :p > > > > Considering the very large number of clients and possible > > configurations, I find it very odd to blame the one writing the email > > instead of the client being used to read said email. > > There. I blamed your mail reader for pointlessly wraping my > conservatively-sized lines. Sometimes it's the writer's MTU, sometimes the > reader's, sometimes the MTA, sometimes the human... Let's deal with each > separately. > > > > An email isn't a PDF, it *will* display differently everywhere. > > Yes, I've mentioned that issue above. > > > > Should I, as an email writer, be careful about using the ')' character > > just because many clients will convert it to a smiley? > > You should, on any medium, be aware of your reader's general limitations. > That doesn't mean that you absolutely must deal with every silly case. > Accidental smileys are frequent enough, especially with computer code, so > I hope that the reader has a way to turn them on and off. Like it should > have a way to temporally use monospaced fonts when someone sends an ascii > diagram. > > > > Though I'm guessing your answer there is "no because my client doesn't > > do it and my client is right and all others are wrong". > > I hope I don't sound that obnoxious ? > > > > It is trivial to detect the rest of an email is just a quote and the > > client should indicate that (it would also be useful for those who do > > quote inline but leave a large quote unanswered at the end), > > All MTUs I know display quotes a bit differently, sometimes even > collapsing them by default. That makes parsing them easy for the user > (though there's still that gmail bug that puts the first line of the reply > inside the quote...), but it's still be nice to avoid having to parse the > quote if the quote wasn't necessary to begin with. > > > > just like it should be trivial for my client to change the flow of text > > to make it readable instead of the mess it makes right now. > > My client (kmail) happens to help with that by re-adding the proper quote > markers when I hit enter inside a quote, but I'd say that the general case > is not trivial. The only MTU that I remember being good at that is gnus > (an emacs mode), most other MTUs I've seen don't help at all. > > > > I find it fascinating that the code of conduct has only had the opposite > > of the intended effect so far. > > The paragraphs about style have been removed from the CoC, so this thread > is not really about CoC anymore. And as much as I dislike top posting, > it's a trivial issue compared to verbal abuse. > > -- > Vincent de Phily > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.pic@REDACTED Thu Mar 26 15:49:16 2015 From: harsha.pic@REDACTED (harsha sri) Date: Thu, 26 Mar 2015 20:19:16 +0530 Subject: [erlang-questions] Issue while starting same worker(gen_server) multiple times in Supervisor Message-ID: Hi, I am trying to start same worker multiple times in Supervisor but its giving me error. Here is my Supervisor: -module(uclient_sup). -behaviour(supervisor). -export([start_link/0, init/1]). -define( CHILD(Name, Args), {Name, { uclient_worker, start_link, [{<<"callmgr">> , 3}] }, permanent, 5000, worker, [] } ). start_link() -> supervisor:start_link({global, ?MODULE}, ?MODULE, _Arg = []). init([]) -> Children = [?CHILD("uc1", Address), ?CHILD("uc2", Address)], {ok, { {one_for_one, 6, 10}, Children }}. I am getting below error: Error: {could_not_start,uclient, {{shutdown, {failed_to_start_child,"uc2",{already_started,<5169.429.0>}}}, {uclient,start,[normal,[]]}}} Please help me in solving this issue. I am new to erlang. Thanks & Regards, SriHarsha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Thu Mar 26 17:11:40 2015 From: radek@REDACTED (Rad Gruchalski) Date: Thu, 26 Mar 2015 17:11:40 +0100 Subject: [erlang-questions] Issue while starting same worker(gen_server) multiple times in Supervisor In-Reply-To: References: Message-ID: <8DC665613BDB402F9FD5EF8DEA3A6341@gruchalski.com> Can you show start_link of the uclient_worker? Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Thursday, 26 March 2015 at 15:49, harsha sri wrote: > Hi, > > I am trying to start same worker multiple times in Supervisor but its giving me error. > Here is my Supervisor: > > > -module(uclient_sup). > > -behaviour(supervisor). > > -export([start_link/0, init/1]). > > -define( > CHILD(Name, Args), > {Name, { > uclient_worker, start_link, [{<<"callmgr">> , 3}] > }, permanent, 5000, worker, [] > } > ). > > start_link() -> > supervisor:start_link({global, ?MODULE}, ?MODULE, _Arg = []). > > init([]) -> > Children = [?CHILD("uc1", Address), ?CHILD("uc2", Address)], > {ok, { {one_for_one, 6, 10}, Children }}. > > I am getting below error: > > Error: {could_not_start,uclient, > {{shutdown, > {failed_to_start_child,"uc2",{already_started,<5169.429.0>}}}, > {uclient,start,[normal,[]]}}} > > > Please help me in solving this issue. I am new to erlang. > > Thanks & Regards, > SriHarsha. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Thu Mar 26 17:15:55 2015 From: radek@REDACTED (Rad Gruchalski) Date: Thu, 26 Mar 2015 17:15:55 +0100 Subject: [erlang-questions] Issue while starting same worker(gen_server) multiple times in Supervisor In-Reply-To: <8DC665613BDB402F9FD5EF8DEA3A6341@gruchalski.com> References: <8DC665613BDB402F9FD5EF8DEA3A6341@gruchalski.com> Message-ID: By the way, you want to use atoms for names: Children = [?CHILD(uc1, Address), ?CHILD(uc2, Address)], Give it a shot. Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Thursday, 26 March 2015 at 17:11, Rad Gruchalski wrote: > Can you show start_link of the uclient_worker? > > > > > > > > > > > Kind regards, > Radek Gruchalski > radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) > de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) > > Confidentiality: > This communication is intended for the above-named person and may be confidential and/or legally privileged. > If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. > > > > On Thursday, 26 March 2015 at 15:49, harsha sri wrote: > > > Hi, > > > > I am trying to start same worker multiple times in Supervisor but its giving me error. > > Here is my Supervisor: > > > > > > -module(uclient_sup). > > > > -behaviour(supervisor). > > > > -export([start_link/0, init/1]). > > > > -define( > > CHILD(Name, Args), > > {Name, { > > uclient_worker, start_link, [{<<"callmgr">> , 3}] > > }, permanent, 5000, worker, [] > > } > > ). > > > > start_link() -> > > supervisor:start_link({global, ?MODULE}, ?MODULE, _Arg = []). > > > > init([]) -> > > Children = [?CHILD("uc1", Address), ?CHILD("uc2", Address)], > > {ok, { {one_for_one, 6, 10}, Children }}. > > > > I am getting below error: > > > > Error: {could_not_start,uclient, > > {{shutdown, > > {failed_to_start_child,"uc2",{already_started,<5169.429.0>}}}, > > {uclient,start,[normal,[]]}}} > > > > > > Please help me in solving this issue. I am new to erlang. > > > > Thanks & Regards, > > SriHarsha. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Thu Mar 26 17:32:40 2015 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 26 Mar 2015 17:32:40 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. Message-ID: Erlang/OTP 18.0-rc1 is available for testing. This is an alpha release, which will be followed by a planned beta release in May and a final OTP 18.0 product release in June 2015. Between the alpha and beta and final release there will be new updates of the master branch with corrections and minor new features. Occasionally there might be new tags which we in that case will communicate and ask you to test. Erlang/OTP 18.0 is a new major release with new features, quite a few (characteristics) improvements, as well as a few incompatibilities. See the Release Notes and the documentation for more details. We would like to ask you to build and test the alpha release and send us your feedback as soon as possible, so that we can make the necessary corrections before OTP 18.0-rc2 and OTP 18.0, respectively. The release contains many changes; thus, some unexpected incompatibilities or issues may have slipped through our tests. Please try to build and run your current products/applications and let us know about any problems. *IMPORTANT INFO when building your own code with this OTP release* Since erlang:now is deprecated your build might stop if you are using "warnings as errors". To let the build through you can turn of warnings for deprecated functions by setting an environment variable like this: export ERL_COMPILER_OPTIONS=nowarn_deprecated_function Some highlights of the release are: - dialyzer: The -dialyzer() attribute can be used for suppressing warnings in a module by specifying functions or warning options. It can also be used for requesting warnings in a module. - erts: The time functionality has been extended. This includes a new API for time, as well as "time warp" modes which alters the behavior when system time changes. You are strongly encouraged to use the new API instead of the old API based on erlang:now/0. erlang:now/0 has been deprecated since it will always be a scalability bottleneck. For more information see the Time and Time Correction chapter of the ERTS User's Guide. Here is a link http://www.erlang.org/documentation/doc-7.0-rc1/erts-7.0/doc/html/time_correction.html - erts: Beside the API changes and time warp modes a lot of scalability and performance improvements regarding time management has been made. Examples are: - scheduler specific timer wheels, - scheduler specific BIF timer management, - parallel retrieval of monotonic time and system time on OS:es that support it. - erts: The previously introduced "eager check I/O" feature is now enabled by default. - erts/compiler: enhanced support for maps. Big maps new uses a HAMT (Hash Array Mapped Trie) representation internally which makes them more efficient. There is now also support for variables as map keys. - ssl: Remove default support for SSL-3.0 and added padding check for TLS-1.0 due to the Poodle vulnerability. - ssl: Remove default support for RC4 cipher suites, as they are consider too weak. - stdlib: Allow maps for supervisor flags and child specs You can find the Release Notes with more detailed info at http://www.erlang.org/download/otp18rc1_relnotes.pdf You find the source code at github.com in the official Erlang repository. Git tag OTP-18.0-rc1 https://github.com/erlang/otp/tree/OTP-18.0-rc1 You can also read the documentation on-line here: (see the Release Notes mentioned above for release notes which are not updated in the doc, but the new functionality is) http://www.erlang.org/documentation/doc-7.0-rc1/doc/ We also want to thank those that sent us patches, suggestions and bug reports. The Erlang/OTP Team at Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Thu Mar 26 18:21:57 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 26 Mar 2015 10:21:57 -0700 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: Message-ID: <20150326172157.GF33506@ferdair.local> On 03/26, Kenneth Lundin wrote: > - erts: The time functionality has been extended. This includes a > new > API for > time, as well as "time warp" modes which alters the behavior when system > time changes. You are strongly encouraged to use the new API instead of the > old API based on erlang:now/0. erlang:now/0 has been deprecated since it > will always be a scalability bottleneck. > For more information see the Time and Time Correction chapter of the > ERTS User's Guide. Here is a link > http://www.erlang.org/documentation/doc-7.0-rc1/erts-7.0/doc/html/time_correction.html This is a bit complex, but frankly I think it is *great*. The mechanisms are much cleaner than before to understand, moving to specific units is great. Splitting strictly monotonic integers from motonic time is going to be useful in the future, though I'm guessing a few more "accidents" may happen in the code bases of people who haven't read the doc. One question: is this module included in OTP? http://www.erlang.org/documentation/doc-7.0-rc1/erts-7.0/doc/html/time_compat.erl If we're expected to copy it or reimplement it locally, I would add a note to please rename the module with a prefix for your app name (myapp_time_compat) to avoid conflicts when building projects that all use the same module. Regards, Fred. From harsha.pic@REDACTED Thu Mar 26 17:59:15 2015 From: harsha.pic@REDACTED (harsha sri) Date: Thu, 26 Mar 2015 22:29:15 +0530 Subject: [erlang-questions] Issue while starting same worker(gen_server) multiple times in Supervisor In-Reply-To: <8DC665613BDB402F9FD5EF8DEA3A6341@gruchalski.com> References: <8DC665613BDB402F9FD5EF8DEA3A6341@gruchalski.com> Message-ID: Hi Rad, First of all Thank you so much for immediate reply. uclient worker start method: -module(uclient_worker). -behaviour(gen_server). -export([start_link/1]). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -export([fire/0]). -export([add_subscriber/4, spawn_subscriber/3]). -include_lib("amqp_client/include/amqp_client.hrl"). -record(state, {channel,java_port :: port(),java_node :: atom(),queuen,nofs}). -define(RKFormat, "~4.10.0B.~2.10.0B.~2.10.0B.~1.10.0B.~2.10.0B.~2.10.0B.~2.10.0B"). start_link(Pars) -> %%file:write_file("/tmp/rabbit.txt", Pars, [append]), gen_server:start_link({global, ?MODULE}, ?MODULE, Pars, []). %--------------------------- % Gen Server Implementation % -------------------------- init(Pars) -> Regarding to CHILD in supervisor: actually my initial supervisor is : %%%%%%%% -module(uclient_sup). -behaviour(supervisor). -export([start_link/0, init/1]). start_link() -> supervisor:start_link({local, ?MODULE}, ?MODULE, _Arg = []). init([]) -> {ok, {{one_for_one, 1, 10}, [{uclient_worker, {uclient_worker, start_link, [{<<"callmgr">> , 3}]}, permanent, 10, worker, [uclient_worker]} ]}}. %%%%%%%%%%%%% But i changed above code for invoking multiple worker under supervisor based on conditions. In that process i just changed code using CHILD. Regards, Harsha On Thu, Mar 26, 2015 at 9:41 PM, Rad Gruchalski wrote: > Can you show start_link of the uclient_worker? > > Kind regards, > Radek Gruchalski > radek@REDACTED > de.linkedin.com/in/radgruchalski/ > > > *Confidentiality:*This communication is intended for the above-named > person and may be confidential and/or legally privileged. > If it has come to you in error you must take no action based on it, nor > must you copy or show it to anyone; please delete/destroy and inform the > sender immediately. > > On Thursday, 26 March 2015 at 15:49, harsha sri wrote: > > Hi, > > I am trying to start same worker multiple times in Supervisor but its > giving me error. > Here is my Supervisor: > > > -module(uclient_sup). > > -behaviour(supervisor). > > -export([start_link/0, init/1]). > > -define( > CHILD(Name, Args), > {Name, { > uclient_worker, start_link, [{<<"callmgr">> , 3}] > }, permanent, 5000, worker, [] > } > ). > > start_link() -> > supervisor:start_link({global, ?MODULE}, ?MODULE, _Arg = []). > > init([]) -> > Children = [?CHILD("uc1", Address), ?CHILD("uc2", Address)], > {ok, { {one_for_one, 6, 10}, Children }}. > > I am getting below error: > > Error: {could_not_start,uclient, > {{shutdown, > > {failed_to_start_child,"uc2",{already_started,<5169.429.0>}}}, > {uclient,start,[normal,[]]}}} > > > Please help me in solving this issue. I am new to erlang. > > Thanks & Regards, > SriHarsha. > _______________________________________________ > 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 26 19:12:06 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 26 Mar 2015 19:12:06 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 5:32 PM, Kenneth Lundin wrote: > Erlang/OTP 18.0-rc1 is available for testing. I'm asking this one for the community: what is the status of dirty schedulers and release 18.0? Will they be enabled by default, or will they still be behind a compiler flag? Also, the time API is really well-designed. I can't wait to use it. The idea of decoupling time and then disabling time smearing but enabling monitors for time changes is probably the right way forward. One could always imagine having a "smeared time" as well in the future if someone really needs the smearing behavior. But one could also argue such things should reside in NTP relays/proxies. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Thu Mar 26 19:13:24 2015 From: radek@REDACTED (Rad Gruchalski) Date: Thu, 26 Mar 2015 19:13:24 +0100 Subject: [erlang-questions] Issue while starting same worker(gen_server) multiple times in Supervisor In-Reply-To: References: <8DC665613BDB402F9FD5EF8DEA3A6341@gruchalski.com> Message-ID: <92B8BB3A19E242F7A192E379DD5CE79D@gruchalski.com> The problem is in the worker: -module(uclient_worker). ... start_link(Pars) -> %%file:write_file("/tmp/rabbit.txt", Pars, [append]), gen_server:start_link({global, ?MODULE}, ?MODULE, Pars, []). ?MODULE is expanded to uclient_worker at compile time and registered globally using {global, ?MODULE}, your child is starting twice under {global, uclient_worker}, hence the error. What?s after global, the name of the instance, has to be unique when starting multiple times. Same applies to local. What you most likely want to do, is the following: -define( CHILD(Name, Args), {Name, { uclient_worker, start_link, [{Name, <<"callmgr">> , 3}] }, permanent, 5000, worker, [] } ). ? % use an atom here, not strings... Children = [?CHILD(uc1, Address), ?CHILD(uc2, Address)], And then, in the worker: start_link({ Name, Bin, IntArg }) -> gen_server:start_link({global, Name}, ?MODULE, { Bin, Args }, []). Hope it makes sense! Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Thursday, 26 March 2015 at 17:59, harsha sri wrote: > Hi Rad, > > First of all Thank you so much for immediate reply. > > uclient worker start method: > > > > -module(uclient_worker). > -behaviour(gen_server). > > -export([start_link/1]). > > -export([init/1, handle_call/3, handle_cast/2, handle_info/2, > terminate/2, code_change/3]). > > -export([fire/0]). > > -export([add_subscriber/4, spawn_subscriber/3]). > > -include_lib("amqp_client/include/amqp_client.hrl"). > > -record(state, {channel,java_port :: port(),java_node :: atom(),queuen,nofs}). > > -define(RKFormat, > "~4.10.0B.~2.10.0B.~2.10.0B.~1.10.0B.~2.10.0B.~2.10.0B.~2.10.0B"). > > > start_link(Pars) -> > %%file:write_file("/tmp/rabbit.txt", Pars, [append]), > gen_server:start_link({global, ?MODULE}, ?MODULE, Pars, []). > > %--------------------------- > % Gen Server Implementation > % -------------------------- > > init(Pars) -> > > > Regarding to CHILD in supervisor: > > actually my initial supervisor is : > %%%%%%%% > -module(uclient_sup). > > -behaviour(supervisor). > > -export([start_link/0, init/1]). > > start_link() -> > supervisor:start_link({local, ?MODULE}, ?MODULE, _Arg = []). > > init([]) -> > {ok, {{one_for_one, 1, 10}, > [{uclient_worker, > {uclient_worker, start_link, [{<<"callmgr">> , 3}]}, > permanent, > 10, > worker, > [uclient_worker]} > ]}}. > %%%%%%%%%%%%% > > > But i changed above code for invoking multiple worker under supervisor based on conditions. > In that process i just changed code using CHILD. > > Regards, > Harsha > > > > On Thu, Mar 26, 2015 at 9:41 PM, Rad Gruchalski wrote: > > Can you show start_link of the uclient_worker? > > > > > > > > > > > > > > > > > > > > > > Kind regards, > > Radek Gruchalski > > radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) > > de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) > > > > Confidentiality: > > This communication is intended for the above-named person and may be confidential and/or legally privileged. > > If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. > > > > > > > > On Thursday, 26 March 2015 at 15:49, harsha sri wrote: > > > > > > > > > Hi, > > > > > > I am trying to start same worker multiple times in Supervisor but its giving me error. > > > Here is my Supervisor: > > > > > > > > > -module(uclient_sup). > > > > > > -behaviour(supervisor). > > > > > > -export([start_link/0, init/1]). > > > > > > -define( > > > CHILD(Name, Args), > > > {Name, { > > > uclient_worker, start_link, [{<<"callmgr">> , 3}] > > > }, permanent, 5000, worker, [] > > > } > > > ). > > > > > > start_link() -> > > > supervisor:start_link({global, ?MODULE}, ?MODULE, _Arg = []). > > > > > > init([]) -> > > > Children = [?CHILD("uc1", Address), ?CHILD("uc2", Address)], > > > {ok, { {one_for_one, 6, 10}, Children }}. > > > > > > I am getting below error: > > > > > > Error: {could_not_start,uclient, > > > {{shutdown, > > > {failed_to_start_child,"uc2",{already_started,<5169.429.0>}}}, > > > {uclient,start,[normal,[]]}}} > > > > > > > > > Please help me in solving this issue. I am new to erlang. > > > > > > Thanks & Regards, > > > SriHarsha. > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felixgallo@REDACTED Thu Mar 26 19:44:47 2015 From: felixgallo@REDACTED (Felix Gallo) Date: Thu, 26 Mar 2015 11:44:47 -0700 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: Message-ID: The new time functionality looks excellent, thank you very much! I feel like erlang:unique_integer/1's doc, as well as the time page where it's discussed, could use some warnings. In particular, the invariants are lost if the value leaves the currently running erlang instance; either by being included in a message to another instance, or by roundtripping through any IO path, for example restoring state from a text file or database after an instance or system crash. A number of novel edge-casey production surprises lie in wait for the uncareful implementor. Does the OTP team have any intention to, or thoughts on, implementing 'distributed' as a possible ModifierList entry for unique_integer/1, ensuring unique integers with respect to the visible nodes? F. On Thu, Mar 26, 2015 at 11:12 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Thu, Mar 26, 2015 at 5:32 PM, Kenneth Lundin > wrote: > >> Erlang/OTP 18.0-rc1 is available for testing. > > > I'm asking this one for the community: what is the status of dirty > schedulers and release 18.0? Will they be enabled by default, or will they > still be behind a compiler flag? > > Also, the time API is really well-designed. I can't wait to use it. The > idea of decoupling time and then disabling time smearing but enabling > monitors for time changes is probably the right way forward. One could > always imagine having a "smeared time" as well in the future if someone > really needs the smearing behavior. But one could also argue such things > should reside in NTP relays/proxies. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Mar 26 19:59:58 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 26 Mar 2015 21:59:58 +0300 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: Message-ID: About dirty schedulers: seems that they still can block node. I've tried again to enable them on 17.4, but had to return back to self-made thread pool. What should I do to help to debug it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Thu Mar 26 21:00:51 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 26 Mar 2015 21:00:51 +0100 Subject: [erlang-questions] crypto EVP transition Message-ID: What's the status of transitioning the crypto nifs to the EVP API? The last I recall there were attempts to land this in 18.0. From vinoski@REDACTED Thu Mar 26 22:00:21 2015 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 26 Mar 2015 17:00:21 -0400 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 2:59 PM, Max Lapshin wrote: > About dirty schedulers: seems that they still can block node. I've tried > again to enable them on 17.4, but had to return back to self-made thread > pool. > > What should I do to help to debug it? > Supply me with the details of what you're doing, showing me code if possible. The smaller the test case that shows the problem, the better. Also please explain what you mean by "block node". --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Mar 26 22:13:01 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 27 Mar 2015 00:13:01 +0300 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: Message-ID: Here is our wrapper around ffmpeg libavcodec: https://gist.github.com/maxlapshin/b0a1cb075daf1f2110b9 When I use dirty nifs (uncomment // #define USE_DIRTY_NIFS), after some time of working, whole erlang VM goes down in CPU usage, slowdown response in console and starts timeouting on HTTP requests. When I start thread per instance of encoder/decoder, everything works. Usual time, spent in one such long call is around 10-20 ms. On Fri, Mar 27, 2015 at 12:00 AM, Steve Vinoski wrote: > > > On Thu, Mar 26, 2015 at 2:59 PM, Max Lapshin > wrote: > >> About dirty schedulers: seems that they still can block node. I've tried >> again to enable them on 17.4, but had to return back to self-made thread >> pool. >> >> What should I do to help to debug it? >> > > Supply me with the details of what you're doing, showing me code if > possible. The smaller the test case that shows the problem, the better. > Also please explain what you mean by "block node". > > --steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Thu Mar 26 22:48:18 2015 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Thu, 26 Mar 2015 22:48:18 +0100 Subject: [erlang-questions] Path to erl In-Reply-To: References: <7460EBDDCF52084A849D0F271CE059B809AEC041@ESESSMB101.ericsson.se> <55127B10.6020309@gmail.com> Message-ID: <55147EA2.90106@wanadoo.fr> Hi > init:get_arguments(). [{root,["/usr/local/lib/erlang"]}, {progname,["erl"]}, {home,["/home/eric"]}] but be aware that heart:get_cmd/0 can give you the command that HEART will use in case of emulator reboot. This command may have been overridden by heart:set_cmd/1 and can be different. Regards From jozsef.berces@REDACTED Fri Mar 27 00:11:03 2015 From: jozsef.berces@REDACTED (=?iso-8859-1?Q?J=F3zsef_B=E9rces?=) Date: Thu, 26 Mar 2015 23:11:03 +0000 Subject: [erlang-questions] Path to erl In-Reply-To: <55147EA2.90106@wanadoo.fr> References: <7460EBDDCF52084A849D0F271CE059B809AEC041@ESESSMB101.ericsson.se> <55127B10.6020309@gmail.com> <55147EA2.90106@wanadoo.fr> Message-ID: <7460EBDDCF52084A849D0F271CE059B809AEDD5B@ESESSMB101.ericsson.se> Yesss. This one looks universal. /proc and BINDIR work on Linux but not on Windows. Thanks everyone for the answers. -----Original Message----- From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of PAILLEAU Eric Sent: Friday, March 27, 2015 04:48 To: erlang-questions@REDACTED Subject: Re: [erlang-questions] Path to erl Hi > init:get_arguments(). [{root,["/usr/local/lib/erlang"]}, {progname,["erl"]}, {home,["/home/eric"]}] but be aware that heart:get_cmd/0 can give you the command that HEART will use in case of emulator reboot. This command may have been overridden by heart:set_cmd/1 and can be different. Regards _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Fri Mar 27 00:58:06 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 27 Mar 2015 12:58:06 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <1759336.jlCHC02v9p@moltowork> <5513E8D8.8010308@ninenines.eu> <5129072.byzI9vbLKs@moltowork> Message-ID: <8E643E4A-8214-42AD-873C-6D89D3070585@cs.otago.ac.nz> On 27/03/2015, at 4:24 am, Benoit Chesneau wrote: > These discussions about top posting (which is the default in most mua now) seem quite frivolous... > > Top posting is about providing an *over*view , what generally follows is the context of this overview (ie the previous mail). In my mail reader, top posting is pointless, because the message they are failing to prune is right there in the window anyway. Should I *want* to read the whole unedited context, it's just *there*. This may be one of the reasons I see no advantage in top posting. YMMV. From mononcqc@REDACTED Fri Mar 27 01:23:52 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 26 Mar 2015 17:23:52 -0700 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: Message-ID: <20150326233846.GA65365@ferdair.local> On 03/26, Felix Gallo wrote: >Does the OTP team have any intention to, or thoughts on, implementing >'distributed' as a possible ModifierList entry for unique_integer/1, >ensuring unique integers with respect to the visible nodes? Sounds like you'd like {node(), Integer} or possibly {make_ref(), Integer}. If you have a value that is 'unique' for a node (as long as it's alove), then including something that uniquely identifies that node along with that node-unique value tends to give acceptable results. Things are trickier if you want this to keep working over multiple node restarts. From ok@REDACTED Fri Mar 27 03:46:45 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 27 Mar 2015 15:46:45 +1300 Subject: [erlang-questions] Learning from Open Source projects? In-Reply-To: References: Message-ID: <368F0252-894F-423F-A2C7-D2BA7725AF92@cs.otago.ac.nz> On 26/03/2015, at 6:23 pm, Harit Himanshu wrote: > ? How do you read/learn open-source library? > ? What techniques do you use to make sure you understand it correctly? Fred H?bert's free e-book "Stuff goes bad: Erlang in Anger" at http://www.erlang-in-anger.com starts with Chapter 1 "How to Dive into a Code Base". Put it this way; if this book were not free, I would be begging my department to buy me a copy even if it was pretty expensive. It's a really practical book by an author who knows his Erlang onions. I believe that you are likely to find chapter 1 helpful. It would be even more helpful if there were more of it! I don't think there is much difference between reading open source libraries and reading closed source ones. I've seen the Windows Research Kernel, the sources of Open Solaris (formerly closed), the sources of the JDK (formerly closed), a couple of C/C++/Fortran compilers that were open sourced having been closed, the sources of two commercial-but-you-get-the-sources statistics packages. I have the sources for 3 open Smalltalks and 3 commercial-but-free-for-personal-use ones. For that matter, Quintus Prolog had some of the best customer- level documentation I've ever seen, but the internal documentation started good but rapidly got out of date and wasn't maintained. I tell people that when I had to maintain it, the core module of the Prolog compiler had two comments. One was "This doesn't work" commenting out a minor optimisation, and the other was the copyright notice. (I did _not_ leave it like that!) So you read/learn open-source code the same way you read/learn *any* code that you have to work with. Try some examples and see what gets executed. (Chapter 9 "Tracing" will be useful there.) Read just those bits. Get some ideas what neighbouring code might do. Construct some more examples and see what they do. It's a problem-solving activity. Make notes of the questions you come up with, and answers if any. From bengt.kleberg@REDACTED Fri Mar 27 07:09:55 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 27 Mar 2015 07:09:55 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <1759336.jlCHC02v9p@moltowork> References: <55126038.4050706@ericsson.com> <1759336.jlCHC02v9p@moltowork> Message-ID: <5514F433.5070602@ericsson.com> Greetings, I think of top posting vs inline comments as something akin to emacs vs vi. There is no motiviation for me to discuss the matter in a context like the strongly one sided sentiments shown below. bengt On 03/26/2015 11:50 AM, Vincent de Phily wrote: > On Thursday 26 March 2015 16:07:03 Richard A. O'Keefe wrote: >> As I moderate no mailing list, my opinions have as much >> force as a politician's promise. But I shall continue >> to value inline-annotated messages more highly than >> top-posted ones. > It's like going to a job interview badly dressed, punctuating your everyday > language with swear words, or leaving lots of grammar/spelling errors in your > texts. Some people you speak to won't mind, care, or notice. But many people > will notice, and the majority of those will not tell you about it : they'll > just tend to disregard you in more or less subtle ways. In the end, it's your > problem more than their's. > > Top-posting is the spelling mistake of mailing lists. Some readers won't care, > and some will find the message annoying and/or harder to understand. If they > do, it's the top-poster's loss. > From bengt.kleberg@REDACTED Fri Mar 27 07:23:39 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 27 Mar 2015 07:23:39 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <55126038.4050706@ericsson.com> Message-ID: <5514F76B.6090002@ericsson.com> Greetings, Blaming top posts when somebody mixes top posts and inline comments, in a difficult to realize manner, is perhaps unfair. Could it not be the inline part that is wrong, instead? In the end I think that it is the quality of the post, even if it is a top post, that has the final say. Given a background of no problems with heavily edited quotes and inline comments I understand that such an experience would make one like that practice. My experience is not one of those. I would prefer no editing of what I have written. It is therefore I top post. Do unto others etc. bengt On 03/26/2015 04:07 AM, Richard A. O'Keefe wrote: > On 25/03/2015, at 8:14 pm, Bengt Kleberg wrote: >> To me the good part with top posting is the knowledge that nobody is editing the quoted part. > But how do you *get* that knowledge? > The mere fact that something looks like a top posting > is no guaranteed that the quoted material hasn't been > edited. > > Nor do I believe that editing per se is in any way > wrong or unhelpful. As long as quoted material is > clearly quoted, and is not distorted, reducing it > is *helpful*. It directs the reader's attention to > the part(s) that the 2nd poster is actually responding to. > >> To trawl carefully through the quoted content in a top post message looking for added content is futile. If there is more content it is not a top post. > Yes, but it's not as if top posts arrived in purple > and inline annotation arrived in green. You can't be > *sure* that a top post *is* a top post until you have > looked. > > My memory may be deceiving me, but I believe I've seen > several messages in this very list where I nearly missed > some additional comment because it started out *looking* > like a top post. > >> There might be statistics that show how top posters write with less effort than inline commentors. That I have not heard of it does not prove anything. But I much prefer a effortless email that is helpful, > One of the arguments that has been made in this thread, > and not as far as I know disputed, is that many people > these days top-post without thinking about it because > many modern MUAs make top-posting particularly easy. > > (For what it's worth, I am using Apple Mail version > 7.3 (1878.6), released last year, and in-line annotation > is perfectly straightforward. But I have inadequate > knowledge of other modern MUAs to make general claims.) > > It is conceivable that such messages might be helpful; > I have no statistics on this either. Only anecdotal > evidence that I've seen top-posted messages in several > mailing lists that their authors followed up with an > "oops, sorry, I didn't fully read what I was responding to." > I don't recall seeing such follow-ups for inline-annotated > messages. That's just an impression from a memory that's > like a sieve with holes in it. > > It would be interesting if someone with time on their hands > investigated to see if top posted messages *were* noticeably > helpful. And it's not as if it were the least bit *hard* to > annotate in-line. > > To me, one issue is that in-line annotation provides > evidence that the person writing the new comments has > at least given every part of the message they are > responding to a chance to pass by their eyeballs; they > might just possibly have read it. > > There is also the helpfulness issue that each item of > reply is right next to the thing it's a reply *to*; > this makes it much easier for me to understand an > inline-annotated message than a top-posted one. > > As I moderate no mailing list, my opinions have as much > force as a politician's promise. But I shall continue > to value inline-annotated messages more highly than > top-posted ones. > > > From ulf@REDACTED Fri Mar 27 07:51:05 2015 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 27 Mar 2015 07:51:05 +0100 Subject: [erlang-questions] distributed erlang machine crash problem In-Reply-To: References: Message-ID: <9D66D211-38CE-4757-9074-D0ABF2673F92@feuerlabs.com> > On 26 Mar 2015, at 14:42, Przemys?aw Wycisk wrote: > > We have two ideas how to solve that problem: > - write an application (lets call it Y), which can store all needed data to restart a X application, there could be several instances of Y on several machines, which will have to be up to date with X application's state to restart it without lose of data, > - keep exact mirror of X application on several machines, only one responsive, other only for keeping processes, and state data. Mirrors would just create mirror processes and update its state up to master X application. > On master X application crash, one of mirrors would just "unlock" and run as master. What I suggest you do first is to analyze your system requirements from a failure recovery standpoint: what level of service outage can you live with? Mirroring state in real-time is of course possible, but as you?ve noted, very expensive. In the old AXD 301, the basic redundancy mechanism was asynchronous stable-state replication, combined with an audit after failure. In that particular system, we had ca 15 seconds before protocol timers would start firing and a service outage becoming noticeable*. We went through the various data items and decided which data could be reconstituted from other data, and which couldn?t. We also assessed the probability of certain failures and calculated the amount of data loss that would be acceptable given the availability level we were aiming for. In other words, we had neither a hot nor cold standby, but something in between - warm standby. BR, Ulf W * This was possible because the actual data stream handling was physically separate from the control layer. Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Mar 27 08:37:28 2015 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 27 Mar 2015 20:37:28 +1300 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <5514F76B.6090002@ericsson.com> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <55126038.4050706@ericsson.com> <5514F76B.6090002@ericsson.com> Message-ID: <80AA9CBB-205F-4CA6-A0D3-56DFC2F37738@cs.otago.ac.nz> On 27/03/2015, at 7:23 pm, Bengt Kleberg wrote: I think there is some point in continuing the discussion, but NOT as a discussion about top-posting vs inline annotation. > Given a background of no problems with heavily edited quotes and inline comments I understand that such an experience would make one like that practice. My experience is not one of those. I would prefer no editing of what I have written. It is therefore I top post. Do unto others etc. We are now onto something that has nothing to do with the mechanics of mail. This is perhaps the key question. One reason it is a key question is that Bengt Kleberg's position is one I find morally consistent but could never have imagined it possible to hold. If he's right about selective quoting being wrong, I have been doing bad things for a long time and need to change. So have I? It has been standard practice in the West, for about the last two thousand years, when you quote someone to quote only part. (I'm thinking not just of Augustine and Origen but Clement, Ignatius, Paul, the Evangelists, the fragments we have of the pre-Socratics that survive because they were quoted, ...) To be sure, the tractate "Ethics of the Fathers" (Pirkei Avot) says in chapter 6, verse 6: ... Torah is acquired with forty-eight qualities. These are: study, listening, ...., exactness in conveying a teaching, and saying something in the name of its speaker. Thus we have learned: On who says something in the name of its speaker brings redemption to the world, ... [Quoted from the English translation at http://www.chabad.org/library/article_cdo/aid/2122/jewish/Chapter-Six.htm] This teaches the ethical importance of quoting accurately and attributing correctly. But Pirkei Avot is practically made up of *short* quotations. E.g., chapter 1 verse 12: ... Hillel would say: Be of the disciples of Aaron--- a lover of peace, a pursuer of peace, one who loves the creatures and draws them close to Torah. [http://www.chabad.org/library/article_cdo/aid/682498/jewish/English-Text.htm] For the record, I'm not a Jew and never have been, but I find Pirkei Avot edifying. If it was ok to make a tiny extract from Hillel's teaching, how can it be wrong to make an excerpt from mine? Or let's descend to the (deliberately) ridiculous: Lowering the Bar. (www.loweringthebar.net). The recent blog entry "Court: Obligation to Make Sense May Not Be Delegated to Client" quotes *part* of the petition it's holding up to ridicule. (And links to the whole.) Kevin Underhill also quotes *part* of the Court's response. The previous entry, "Minor Woodfoolery in Today's Supreme Court Opinion", quotes *part* of what Justice Kagan wrote and *part* of what Justice Scalia wrote. (There's a link to the full document, just as e-mail messages have message-IDs to track quoting.) Or for an example from our own discipline, consider http://tug.org/TUGboat/tb34-3/tb108reviews-knuth.pdf That's David Walden reviewing the book "The Essential Knuth", "primarily an interview of Don Knuth by Edgar Daylight". In that review, David Walden quotes just *four sentences* out of 90 pages. If it's OK to extract one tiny point out of a book and comment on that, when it's *KNUTH* in question, how could it be wrong to edit my messages? Heavily! Seriously, I do not have a right to expect, and I do not expect, that anything I say, if quoted, will be quoted in full. The most I can expect is that the attribution be correct and the editing be fair. ?ric Pallieau (eric.pailleau@REDACTED) already directed our attention to http://tools.ietf.org/html/rfc1855 which is quite explicit. Section 2.1.1 says ... You may shorten the message and quote only relevant parts, but be sure you give proper attribution. ... This is basically the Pirkei Avot rule. So I have two questions. - For Bengt Kleberg: why do you desire e-mail quoting to be so different from quoting practice in other verbal media? - For the rest of us: if there is to be a code of conduct, is it generally agreed that * quoting extracts is OK * quoting in a way that distorts what the author meant is not OK * you should at least try to get attribution right or is Bengt Kleberg's position common? From mononcqc@REDACTED Fri Mar 27 08:48:48 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 27 Mar 2015 00:48:48 -0700 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <80AA9CBB-205F-4CA6-A0D3-56DFC2F37738@cs.otago.ac.nz> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <55126038.4050706@ericsson.com> <5514F76B.6090002@ericsson.com> <80AA9CBB-205F-4CA6-A0D3-56DFC2F37738@cs.otago.ac.nz> Message-ID: <20150327074847.GC65365@ferdair.local> On 03/27, Richard A. O'Keefe wrote: >- For the rest of us: if there is to be a > code of conduct, is it generally agreed that > * quoting extracts is OK > * quoting in a way that distorts what the > author meant is not OK > * you should at least try to get attribution right > or is Bengt Kleberg's position common? > I believe the code of conduct no longer contains style guidelines as of http://erlang.org/pipermail/erlang-questions/2015-March/083958.html, although this doesn't invalidate the question in its original context. From daniel.abrahamsson@REDACTED Fri Mar 27 10:52:46 2015 From: daniel.abrahamsson@REDACTED (Daniel Abrahamsson) Date: Fri, 27 Mar 2015 10:52:46 +0100 Subject: [erlang-questions] Fail to parse utf-8 encoded XML Message-ID: Hi, I'm bit confused about the behaviour of xmerl_scan when dealing with utf-8 data. In short, the XML parser chokes when it encounters a "?", but not if I specify the encoding as "latin1". Other parsers in other languages (e.g. nokogiri in Ruby) seem to handle this just fine. I've also run the sample XML through various web validators, and they all say it is valid. Is this a bug in xmerl or am I missing something obvious? Example session below: danabr@REDACTED ~> echo -n "?mlaut" > /tmp/test.xml danabr@REDACTED ~> erl Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.3 (abort with ^G) 1> {ok, S} = file:read_file("/tmp/test.xml"). {ok,<<"?mlaut"/utf8>>} 2> xmerl_scan:string(unicode:characters_to_list(S)). 3414- fatal: {error,{wfc_Legal_Character,{error,{bad_character,252}}}} ** exception exit: {fatal,{{error,{wfc_Legal_Character,{error,{bad_character,252}}}}, {file,file_name_unknown}, {line,1}, {col,47}}} in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) in call from xmerl_scan:scan_char_data/5 (xmerl_scan.erl, line 2703) in call from xmerl_scan:scan_content/11 (xmerl_scan.erl, line 2615) in call from xmerl_scan:scan_element/12 (xmerl_scan.erl, line 2128) in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 570) in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) 3> xmerl_scan:string(unicode:characters_to_list(S), [{encoding, "latin1"}]). {{xmlElement,root,root,[], {xmlNamespace,[],[]}, [],1,[], [{xmlText,[{root,1}],1,[],"?mlaut",text}], [],"/home/danabr",undeclared}, []} //Daniel Abrahamsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Mar 27 11:27:25 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 27 Mar 2015 11:27:25 +0100 Subject: [erlang-questions] Fail to parse utf-8 encoded XML In-Reply-To: References: Message-ID: <5515308D.5080706@ninenines.eu> Hello, 252 (what your "?" gives you) is not a valid Unicode code point. See https://en.wikipedia.org/wiki/UTF-8#Description "One-byte codes are used only for the ASCII values 0 through 127." Guessing the file you read is actually latin1 and not UTF-8. On 03/27/2015 10:52 AM, Daniel Abrahamsson wrote: > Hi, > > I'm bit confused about the behaviour of xmerl_scan when dealing with > utf-8 data. In short, the XML parser chokes when it encounters a "?", > but not if I specify the encoding as "latin1". Other parsers in other > languages (e.g. nokogiri in Ruby) seem to handle this just fine. I've > also run the sample XML through various web validators, and they all say > it is valid. > > Is this a bug in xmerl or am I missing something obvious? > > Example session below: > > danabr@REDACTED ~> echo -n " encoding=\"UTF-8\"?>?mlaut" > /tmp/test.xml > danabr@REDACTED ~> erl > Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] [async-threads:10] > [hipe] [kernel-poll:false] > > Eshell V6.3 (abort with ^G) > 1> {ok, S} = file:read_file("/tmp/test.xml"). > {ok,<<" encoding=\"UTF-8\"?>?mlaut"/utf8>>} > 2> xmerl_scan:string(unicode:characters_to_list(S)). > 3414- fatal: {error,{wfc_Legal_Character,{error,{bad_character,252}}}} > ** exception exit: > {fatal,{{error,{wfc_Legal_Character,{error,{bad_character,252}}}}, > {file,file_name_unknown}, > {line,1}, > {col,47}}} > in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) > in call from xmerl_scan:scan_char_data/5 (xmerl_scan.erl, line 2703) > in call from xmerl_scan:scan_content/11 (xmerl_scan.erl, line 2615) > in call from xmerl_scan:scan_element/12 (xmerl_scan.erl, line 2128) > in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 570) > in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) > 3> xmerl_scan:string(unicode:characters_to_list(S), [{encoding, "latin1"}]). > {{xmlElement,root,root,[], > {xmlNamespace,[],[]}, > [],1,[], > [{xmlText,[{root,1}],1,[],"?mlaut",text}], > [],"/home/danabr",undeclared}, > []} > > //Daniel Abrahamsson > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From daniel.abrahamsson@REDACTED Fri Mar 27 11:46:34 2015 From: daniel.abrahamsson@REDACTED (Daniel Abrahamsson) Date: Fri, 27 Mar 2015 11:46:34 +0100 Subject: [erlang-questions] Fail to parse utf-8 encoded XML In-Reply-To: <5515308D.5080706@ninenines.eu> References: <5515308D.5080706@ninenines.eu> Message-ID: Hi Lo?c, It is a valid unicode code point (http://en.wikipedia.org/wiki/%C3%9C) . If it wasn't I would have expect either the output of line 1 (which says it is a utf-8 encoded binary), to show something different, or at least the "characters_to_list" call to fail. //Daniel On Fri, Mar 27, 2015 at 11:27 AM, Lo?c Hoguin wrote: > Hello, > > 252 (what your "?" gives you) is not a valid Unicode code point. > > See https://en.wikipedia.org/wiki/UTF-8#Description > > "One-byte codes are used only for the ASCII values 0 through 127." > > Guessing the file you read is actually latin1 and not UTF-8. > > > On 03/27/2015 10:52 AM, Daniel Abrahamsson wrote: > >> Hi, >> >> I'm bit confused about the behaviour of xmerl_scan when dealing with >> utf-8 data. In short, the XML parser chokes when it encounters a "?", >> but not if I specify the encoding as "latin1". Other parsers in other >> languages (e.g. nokogiri in Ruby) seem to handle this just fine. I've >> also run the sample XML through various web validators, and they all say >> it is valid. >> >> Is this a bug in xmerl or am I missing something obvious? >> >> Example session below: >> >> danabr@REDACTED ~> echo -n "> encoding=\"UTF-8\"?>?mlaut" > /tmp/test.xml >> danabr@REDACTED ~> erl >> Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] [async-threads:10] >> [hipe] [kernel-poll:false] >> >> Eshell V6.3 (abort with ^G) >> 1> {ok, S} = file:read_file("/tmp/test.xml"). >> {ok,<<"> encoding=\"UTF-8\"?>?mlaut"/utf8>>} >> 2> xmerl_scan:string(unicode:characters_to_list(S)). >> 3414- fatal: {error,{wfc_Legal_Character,{error,{bad_character,252}}}} >> ** exception exit: >> {fatal,{{error,{wfc_Legal_Character,{error,{bad_character,252}}}}, >> {file,file_name_unknown}, >> {line,1}, >> {col,47}}} >> in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) >> in call from xmerl_scan:scan_char_data/5 (xmerl_scan.erl, line 2703) >> in call from xmerl_scan:scan_content/11 (xmerl_scan.erl, line 2615) >> in call from xmerl_scan:scan_element/12 (xmerl_scan.erl, line 2128) >> in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 570) >> in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) >> 3> xmerl_scan:string(unicode:characters_to_list(S), [{encoding, >> "latin1"}]). >> {{xmlElement,root,root,[], >> {xmlNamespace,[],[]}, >> [],1,[], >> [{xmlText,[{root,1}],1,[],"?mlaut",text}], >> [],"/home/danabr",undeclared}, >> []} >> >> //Daniel Abrahamsson >> >> >> _______________________________________________ >> 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 essen@REDACTED Fri Mar 27 11:50:52 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 27 Mar 2015 11:50:52 +0100 Subject: [erlang-questions] Fail to parse utf-8 encoded XML In-Reply-To: References: <5515308D.5080706@ninenines.eu> Message-ID: <5515360C.7070704@ninenines.eu> I meant it is not a valid value in UTF-8. But you're right, the issue is not there, sorry. On 03/27/2015 11:46 AM, Daniel Abrahamsson wrote: > Hi Lo?c, > > It is a valid unicode code point (http://en.wikipedia.org/wiki/%C3%9C) . > If it wasn't I would have expect either the output of line 1 (which says > it is a utf-8 encoded binary), to show something different, or at least > the "characters_to_list" call to fail. > > //Daniel > > On Fri, Mar 27, 2015 at 11:27 AM, Lo?c Hoguin > wrote: > > Hello, > > 252 (what your "?" gives you) is not a valid Unicode code point. > > See https://en.wikipedia.org/wiki/__UTF-8#Description > > > "One-byte codes are used only for the ASCII values 0 through 127." > > Guessing the file you read is actually latin1 and not UTF-8. > > > On 03/27/2015 10:52 AM, Daniel Abrahamsson wrote: > > Hi, > > I'm bit confused about the behaviour of xmerl_scan when dealing with > utf-8 data. In short, the XML parser chokes when it encounters a > "?", > but not if I specify the encoding as "latin1". Other parsers in > other > languages (e.g. nokogiri in Ruby) seem to handle this just fine. > I've > also run the sample XML through various web validators, and they > all say > it is valid. > > Is this a bug in xmerl or am I missing something obvious? > > Example session below: > > danabr@REDACTED ~> echo -n " encoding=\"UTF-8\"?>__?mlaut" > /tmp/test.xml > danabr@REDACTED ~> erl > Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:4:4] > [async-threads:10] > [hipe] [kernel-poll:false] > > Eshell V6.3 (abort with ^G) > 1> {ok, S} = file:read_file("/tmp/test.xml"__). > {ok,<<" encoding=\"UTF-8\"?>__?mlaut"/utf8>>} > 2> xmerl_scan:string(unicode:__characters_to_list(S)). > 3414- fatal: > {error,{wfc_Legal_Character,{__error,{bad_character,252}}}} > ** exception exit: > {fatal,{{error,{wfc_Legal___Character,{error,{bad___character,252}}}}, > {file,file_name_unknown}, > {line,1}, > {col,47}}} > in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) > in call from xmerl_scan:scan_char_data/5 (xmerl_scan.erl, > line 2703) > in call from xmerl_scan:scan_content/11 (xmerl_scan.erl, > line 2615) > in call from xmerl_scan:scan_element/12 (xmerl_scan.erl, > line 2128) > in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, > line 570) > in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) > 3> xmerl_scan:string(unicode:__characters_to_list(S), > [{encoding, "latin1"}]). > {{xmlElement,root,root,[], > {xmlNamespace,[],[]}, > [],1,[], > [{xmlText,[{root,1}],1,[],"__?mlaut",text}], > [],"/home/danabr",undeclared}, > []} > > //Daniel Abrahamsson > > > _________________________________________________ > 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 n.oxyde@REDACTED Fri Mar 27 12:04:20 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 27 Mar 2015 12:04:20 +0100 Subject: [erlang-questions] Fail to parse utf-8 encoded XML In-Reply-To: References: Message-ID: Le 27 mars 2015 ? 10:52, Daniel Abrahamsson a ?crit : > Is this a bug in xmerl or am I missing something obvious? You are missing an inconspicuous thing. xmerl_scan:string/1 takes a list of code units. Try: xmerl_scan:string(binary_to_list(<<"?mlaut"/utf8>>)). Regards. From n.oxyde@REDACTED Fri Mar 27 12:06:47 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 27 Mar 2015 12:06:47 +0100 Subject: [erlang-questions] Learning from Open Source projects? In-Reply-To: References: Message-ID: <0F64DFA8-C99A-40E3-9916-6F973793560F@gmail.com> Le 26 mars 2015 ? 06:23, Harit Himanshu a ?crit : > ? What Erlang projects (specifically) would you recommend a beginner to take a look, read and contribute OTP itself of course. :) Find an itch to scratch, and throw yourself in the source code. From daniel.abrahamsson@REDACTED Fri Mar 27 12:30:51 2015 From: daniel.abrahamsson@REDACTED (Daniel Abrahamsson) Date: Fri, 27 Mar 2015 12:30:51 +0100 Subject: [erlang-questions] Fail to parse utf-8 encoded XML In-Reply-To: References: Message-ID: Thanks Anthony! I see, the error is using characters_to_list in this case, as xmerl wants the "raw" code units, not unicode code points. //Daniel On Fri, Mar 27, 2015 at 12:04 PM, Anthony Ramine wrote: > Le 27 mars 2015 ? 10:52, Daniel Abrahamsson > a ?crit : > > > Is this a bug in xmerl or am I missing something obvious? > > You are missing an inconspicuous thing. > > xmerl_scan:string/1 takes a list of code units. Try: > > xmerl_scan:string(binary_to_list(<<" encoding=\"UTF-8\"?>?mlaut"/utf8>>)). > > Regards. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbenac@REDACTED Fri Mar 27 13:19:07 2015 From: cbenac@REDACTED (Clara Benac Earle) Date: Fri, 27 Mar 2015 13:19:07 +0100 Subject: [erlang-questions] [CFPo] womENcourage 2015 Message-ID: <55154ABB.7070008@fi.upm.es> Dear all, Please consider submitting a poster to womENcourage 2015. This is an event partly organized by the ACM-W (ACM's women in computing). The event will take place in Uppsala (Sweden) September 24-26. The poster may present work in any topic in computing. This is not an only-women event but we would like to specially encourage women in computing to make their work visible. You only need to send a 1-page abstract by the 5th of April. There are scholarships available for students. It would be very cool to see a poster with some Erlang on it ;-) More info http://womencourage.acm.org/call_for_posters.cfm http://womencourage.acm.org/index.cfm Best regards Clara From harsha.pic@REDACTED Fri Mar 27 13:42:23 2015 From: harsha.pic@REDACTED (harsha sri) Date: Fri, 27 Mar 2015 18:12:23 +0530 Subject: [erlang-questions] Lists in recursion Message-ID: Hi, Is it possible to add dynamically add elements to List in recursion? ex: List = [1,2,3] lists:foreach... ..... List = [4 | List] .... (anotherlist). Finally i am expecting in List: [1,2,3,4] Thanks & Regards, Harsha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Fri Mar 27 14:00:25 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 27 Mar 2015 14:00:25 +0100 Subject: [erlang-questions] Lists in recursion In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 1:42 PM, harsha sri wrote: > Is it possible to add dynamically add elements to List in recursion? > There is some indication, you may want to spend time with a good book on Erlang. For instance learnyousomeerlang.com or perhaps Joe Armstrong's book on Erlang. I'm not entirely sure what you want to do, but I can explain to you what happens in the system for the lines below. > ex: List = [1,2,3] > > This will create a list [1,2,3] and bind that list to the name List. > lists:foreach... > > calling, for instance, lists:foreach(fun(Item) -> io:format("~B~n", [Item]) end, List) will not be able to change List. 'foreach/2' is executed for its side-effect only, in this case printing elements. You can use a map/2: List2 = lists:map(fun(Item) -> Item + 3 end, List), but this will * Add three to each element of the list and bind the result to List2, i.e., List2 = [4,5,6] * Not be able to add or remove elements from L * Not change L in any way. The language uses persistent data structures, not ephemeral data structures. > ..... > List = [4 | List] > The expression [4 | List] evaluates to [4,1,2,3] because it prepends (cons'es) 4 in front of the list. If you write List = [4 | List] then the Erlang semantics are: * build up the list [4 | List] --> [4,1,2,3] * Since 'List' is already bound, assert that the current contents of the list is [4,1,2,3]. But List is already bound to [1,2,3], so the assertion is failing. * Crash the program with a badmatch error since the assertion is a failure Finally i am expecting in List: [1,2,3,4] > One way to solve this is to append two lists: List ++ [4]. This will build the single-element list [4] and then append it as a new suffix. If you want to give it a name, it has to be one that hasn't been used already in the scope, e.g., NewList = List ++ [4]. For small lists, this is a viable strategy. For large lists, append can end up being costly in execution speed, but I'd focus on solving problems first and then worrying about performance later. Especially when you are trying to learn what is going on in the first place. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Fri Mar 27 14:27:31 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 27 Mar 2015 14:27:31 +0100 Subject: [erlang-questions] Lists in recursion In-Reply-To: References: Message-ID: <55155AC3.1050104@ericsson.com> Greetings, Is the goal of this exercise to create a bigger list from the call? Then you need lists:foldl/3 or foldr/3 bengt On 03/27/2015 01:42 PM, harsha sri wrote: > Hi, > > Is it possible to add dynamically add elements to List in recursion? > > ex: List = [1,2,3] > > lists:foreach... > > ..... > List = [4 | List] > .... > (anotherlist). > > Finally i am expecting in List: [1,2,3,4] > > Thanks & Regards, > Harsha. > > > _______________________________________________ > 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 Fri Mar 27 16:14:33 2015 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 27 Mar 2015 16:14:33 +0100 Subject: [erlang-questions] Announcing Erlang.org Code of Conduct In-Reply-To: <80AA9CBB-205F-4CA6-A0D3-56DFC2F37738@cs.otago.ac.nz> References: <5509A383.2010703@bestmx.net> <550A738E.704@ericsson.com> <18777803.qjqNZhNtEs@moltowork> <448FEF36-10AD-46BB-A8A7-C4DBC5C15768@cs.otago.ac.nz> <55126038.4050706@ericsson.com> <5514F76B.6090002@ericsson.com> <80AA9CBB-205F-4CA6-A0D3-56DFC2F37738@cs.otago.ac.nz> Message-ID: <551573D9.3020902@ericsson.com> Greetings, It is very kind to suggest that there is some point to this discussion. However, if it is to be about selective quoting in general I have to add that my comments are only supposed to be about this practice in emails. erlang-questions is not the right place for a general discussion of that. The relative badness of heavy editing of quotes in emails is minor. Only 2 people on erlang-questions have expressed a dislike. Neither of these is such strong wording as the top anti-top-posting sentiments that have been seen. So perhaps it would be better to continue with inline comments to avoid incurring that kind of emotions. bengt On 03/27/2015 08:37 AM, Richard A. O'Keefe wrote: > On 27/03/2015, at 7:23 pm, Bengt Kleberg wrote: > > I think there is some point in continuing the discussion, > but NOT as a discussion about top-posting vs inline > annotation. > >> Given a background of no problems with heavily edited quotes and inline comments I understand that such an experience would make one like that practice. My experience is not one of those. I would prefer no editing of what I have written. It is therefore I top post. Do unto others etc. > We are now onto something that has nothing to do with the > mechanics of mail. This is perhaps the key question. One > reason it is a key question is that Bengt Kleberg's > position is one I find morally consistent but could never > have imagined it possible to hold. If he's right about > selective quoting being wrong, I have been doing bad things > for a long time and need to change. So have I? > > > It has been standard practice in the West, for about the > last two thousand years, when you quote someone to quote > only part. (I'm thinking not just of Augustine and Origen > but Clement, Ignatius, Paul, the Evangelists, the fragments > we have of the pre-Socratics that survive because they were > quoted, ...) To be sure, the tractate "Ethics of the Fathers" > (Pirkei Avot) says in chapter 6, verse 6: > > ... Torah is acquired with forty-eight qualities. > These are: study, listening, ...., exactness in > conveying a teaching, and saying something in the > name of its speaker. Thus we have learned: On > who says something in the name of its speaker > brings redemption to the world, ... > > [Quoted from the English translation at http://www.chabad.org/library/article_cdo/aid/2122/jewish/Chapter-Six.htm] > > This teaches the ethical importance of quoting accurately > and attributing correctly. But Pirkei Avot is practically > made up of *short* quotations. E.g., chapter 1 verse 12: > > ... Hillel would say: Be of the disciples of Aaron--- > a lover of peace, a pursuer of peace, one who loves > the creatures and draws them close to Torah. > > [http://www.chabad.org/library/article_cdo/aid/682498/jewish/English-Text.htm] > > For the record, I'm not a Jew and never have been, > but I find Pirkei Avot edifying. > > If it was ok to make a tiny extract from Hillel's teaching, > how can it be wrong to make an excerpt from mine? > > Or let's descend to the (deliberately) ridiculous: > Lowering the Bar. (www.loweringthebar.net). The > recent blog entry "Court: Obligation to Make Sense May > Not Be Delegated to Client" quotes *part* of the > petition it's holding up to ridicule. (And links to > the whole.) Kevin Underhill also quotes *part* of the > Court's response. The previous entry, "Minor Woodfoolery > in Today's Supreme Court Opinion", quotes *part* of what > Justice Kagan wrote and *part* of what Justice Scalia > wrote. (There's a link to the full document, just as > e-mail messages have message-IDs to track quoting.) > > Or for an example from our own discipline, consider > http://tug.org/TUGboat/tb34-3/tb108reviews-knuth.pdf > That's David Walden reviewing the book "The Essential > Knuth", "primarily an interview of Don Knuth by Edgar > Daylight". In that review, David Walden quotes just > *four sentences* out of 90 pages. > > If it's OK to extract one tiny point out of a book > and comment on that, when it's *KNUTH* in question, > how could it be wrong to edit my messages? Heavily! > > Seriously, I do not have a right to expect, and I do > not expect, that anything I say, if quoted, will be > quoted in full. The most I can expect is that the > attribution be correct and the editing be fair. > > ?ric Pallieau (eric.pailleau@REDACTED) already > directed our attention to > http://tools.ietf.org/html/rfc1855 > which is quite explicit. Section 2.1.1 says > > ... You may shorten the message and quote > only relevant parts, but be sure you give > proper attribution. ... > > This is basically the Pirkei Avot rule. > > So I have two questions. > > - For Bengt Kleberg: why do you desire e-mail > quoting to be so different from quoting > practice in other verbal media? > > - For the rest of us: if there is to be a > code of conduct, is it generally agreed that > * quoting extracts is OK > * quoting in a way that distorts what the > author meant is not OK > * you should at least try to get attribution right > or is Bengt Kleberg's position common? > > > > From felixgallo@REDACTED Fri Mar 27 17:00:06 2015 From: felixgallo@REDACTED (Felix Gallo) Date: Fri, 27 Mar 2015 09:00:06 -0700 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: <20150326233846.GA65365@ferdair.local> References: <20150326233846.GA65365@ferdair.local> Message-ID: I do indeed like {node(), Integer}! But it would be highly useful to extend monotonic across distribution as well to permit total order and comparison; although there are some, ah, implementation details... On Thu, Mar 26, 2015 at 5:23 PM, Fred Hebert wrote: > On 03/26, Felix Gallo wrote: > >> Does the OTP team have any intention to, or thoughts on, implementing >> 'distributed' as a possible ModifierList entry for unique_integer/1, >> ensuring unique integers with respect to the visible nodes? >> > > Sounds like you'd like {node(), Integer} or possibly {make_ref(), > Integer}. If you have a value that is 'unique' for a node (as long as it's > alove), then including something that uniquely identifies that node along > with that node-unique value tends to give acceptable results. > > Things are trickier if you want this to keep working over multiple node > restarts. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Mar 27 17:26:28 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 27 Mar 2015 09:26:28 -0700 Subject: [erlang-questions] [ANN] Erlang/OTP 18.0-rc1 is available for testing. In-Reply-To: References: <20150326233846.GA65365@ferdair.local> Message-ID: <20150327162627.GD65365@ferdair.local> On 03/27, Felix Gallo wrote: >I do indeed like {node(), Integer}! But it would be highly useful to >extend monotonic across distribution as well to permit total order and >comparison; although there are some, ah, implementation details... Well this is the root of the issue. To have monotonicity over all nodes means that you enter the CAP theorem, the idea of 2-phase commits or quorum systems. Those are non-trivial choices, and if, for example, the majority of your nodes aren't available, it would be possible for you to never can update the monotonic clock again, and may only keep it flat (if not strictly monotonic). That's why you use a node identifier in there -- it lets you compare things globally to get a partial prder (I can compare a node's data totally, but with other nodes, it's trickier and not always possible). This somewhat embraces the idea that time is relative, especially so on computers where clocks drift and jump around all the time. From harsha.pic@REDACTED Fri Mar 27 18:55:11 2015 From: harsha.pic@REDACTED (harsha sri) Date: Fri, 27 Mar 2015 23:25:11 +0530 Subject: [erlang-questions] Lists in recursion In-Reply-To: References: Message-ID: Hi Jesper, Thank you so much, lists:map helped me for my requirement. Regards, Harsha On Fri, Mar 27, 2015 at 6:30 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Fri, Mar 27, 2015 at 1:42 PM, harsha sri wrote: > >> Is it possible to add dynamically add elements to List in recursion? >> > > There is some indication, you may want to spend time with a good book on > Erlang. For instance learnyousomeerlang.com or perhaps Joe Armstrong's > book on Erlang. I'm not entirely sure what you want to do, but I can > explain to you what happens in the system for the lines below. > > >> ex: List = [1,2,3] >> >> > This will create a list [1,2,3] and bind that list to the name List. > > >> lists:foreach... >> >> > calling, for instance, lists:foreach(fun(Item) -> io:format("~B~n", > [Item]) end, List) will not be able to change List. 'foreach/2' is executed > for its side-effect only, in this case printing elements. You can use a > map/2: List2 = lists:map(fun(Item) -> Item + 3 end, List), but this will > > * Add three to each element of the list and bind the result to List2, > i.e., List2 = [4,5,6] > * Not be able to add or remove elements from L > * Not change L in any way. The language uses persistent data structures, > not ephemeral data structures. > > >> ..... >> List = [4 | List] >> > > The expression [4 | List] evaluates to [4,1,2,3] because it prepends > (cons'es) 4 in front of the list. If you write > > List = [4 | List] > > then the Erlang semantics are: > > * build up the list [4 | List] --> [4,1,2,3] > * Since 'List' is already bound, assert that the current contents of the > list is [4,1,2,3]. But List is already bound to [1,2,3], so the assertion > is failing. > * Crash the program with a badmatch error since the assertion is a failure > > Finally i am expecting in List: [1,2,3,4] >> > > One way to solve this is to append two lists: List ++ [4]. This will build > the single-element list [4] and then append it as a new suffix. If you want > to give it a name, it has to be one that hasn't been used already in the > scope, e.g., > > NewList = List ++ [4]. > > For small lists, this is a viable strategy. For large lists, append can > end up being costly in execution speed, but I'd focus on solving problems > first and then worrying about performance later. Especially when you are > trying to learn what is going on in the first place. > > -- > J. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.pic@REDACTED Fri Mar 27 18:55:49 2015 From: harsha.pic@REDACTED (harsha sri) Date: Fri, 27 Mar 2015 23:25:49 +0530 Subject: [erlang-questions] Lists in recursion In-Reply-To: <55155AC3.1050104@ericsson.com> References: <55155AC3.1050104@ericsson.com> Message-ID: Hi Bengt, Thanks you so much for inputs. Regards, Harsha On Fri, Mar 27, 2015 at 6:57 PM, Bengt Kleberg wrote: > Greetings, > > Is the goal of this exercise to create a bigger list from the call? > Then you need lists:foldl/3 or foldr/3 > > > bengt > > > On 03/27/2015 01:42 PM, harsha sri wrote: > > Hi, > > Is it possible to add dynamically add elements to List in recursion? > > ex: List = [1,2,3] > > lists:foreach... > > ..... > List = [4 | List] > .... > (anotherlist). > > Finally i am expecting in List: [1,2,3,4] > > Thanks & Regards, > Harsha. > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://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 mmzeeman@REDACTED Sat Mar 28 13:48:18 2015 From: mmzeeman@REDACTED (Maas-Maarten Zeeman) Date: Sat, 28 Mar 2015 13:48:18 +0100 Subject: [erlang-questions] crypto EVP transition Message-ID: I?ve been working on this and am in contact with the OTP team. In the past I have done quite some work with openssl?s evp api. The main problem is that it is not possible to implement a drop in replacement for the current ciphers. The api need to change slightly. I?ve implemented a proof of concept nif to test it. For cpu?s supporting AES-NI I get a 5x speedup, so it is definitely worth it. This is the current proof-of-concept api, minus meta-data functions for retrieving block size, iv,- and key length, and a bytes to key function: -spec cipher_init(binary(), binary(), binary(), encrypt | decrypt, boolean()) -> {ok, cipher_ctx()}. cipher_init(_Alg, _Key, _Iv, _Mode, _Padding) -> exit(nif_library_not_loaded). -spec cipher_update(cipher_ctx(), iolist()) -> binary(). cipher_update(_Ctx, _Data) -> exit(nif_library_not_loaded). -spec cipher_final(cipher_ctx()) -> binary(). cipher_final(_Ctx) -> exit(nif_library_not_loaded). Last word from the otp-team was that they think this api is bit too un-erlang because of the rather ugly mutating cipher context. There is not much I can do about that. Openssl does not have a context copy function in its api. Copying the context from call to call could also be impossible when the cipher is implemented in hardware. I?ve suggested that it would be possible to hide the cipher state in a more generic data-transform process. The protocol could be similar to the io-protocol (without seeks), and more erlang like. This would make it possible to also support other types of data-transformations. Think about hex, base64 en/decoders, character set conversions (iconv), and hashing (no transform, process needs extra call to get digest). Such a protocol could be useful for a lot of things. I?m not sure if all this is on track for 18.0 though. Regards, Maas From max.lapshin@REDACTED Sat Mar 28 19:22:26 2015 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 28 Mar 2015 21:22:26 +0300 Subject: [erlang-questions] crypto EVP transition In-Reply-To: References: Message-ID: So without this evp api processor aes-ni is not usex? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellkvist@REDACTED Sun Mar 29 09:46:43 2015 From: hellkvist@REDACTED (Stefan Hellkvist) Date: Sun, 29 Mar 2015 09:46:43 +0200 Subject: [erlang-questions] erlang.mk and yaws Message-ID: Hi (long time lurker of this mailing list) I like erlang.mk and I like yaws and tend to use them in various projects (big thank you to the respective contributors of those projects). But when two of your friends do not get along together you tend to worry. In the yaws case it seems like the problem is that it does have a rebar.config and builds fine with rebar, but it does not have its own copy of rebar locally which many packages seem to include these days (or am I right, what is the norm?). So yaws is not built when it is added as a dependency in an erlang.mk project. I have also tried to add yaws as an AUTOPATCH option in erlang.mk and erlang.mk tries to create a Makefile from the rebar.config but the resulting build fails with a: src/yaws.erl:13: can't find include file "yaws_appdeps.hrl" src/yaws.erl:221: undefined macro 'YAWS_APPDEPS' src/yaws.erl:175: function start_app_deps/0 undefined src/yaws.erl:195: function start_app_deps/0 undefined make[2]: *** [ebin/portal.app] Error 1 make[1]: *** [all] Error 2 So I guess the AUTOPATCH option in erlang.mk does not seem to properly create a working Makefile. The way I always resolve this is to either copy in a rebar script into the yaws folder or go through the autoconf procedure, which is the other way of building yaws, but this is of course a manual process that I would like to avoid. The problem is - which one is the odd one here - should a fix be done in erlang.mk (perhaps in the AUTOPATCH part) or should yaws' build system be fixed? Or should my two friends continue to not get along properly forever and ever? :) /Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sun Mar 29 10:20:12 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 29 Mar 2015 10:20:12 +0200 Subject: [erlang-questions] erlang.mk and yaws In-Reply-To: References: Message-ID: <5517B5BC.3060306@ninenines.eu> On 03/29/2015 09:46 AM, Stefan Hellkvist wrote: > Hi (long time lurker of this mailing list) > > I like erlang.mk and I like yaws and tend to use them > in various projects (big thank you to the respective contributors of > those projects). But when two of your friends do not get along together \o/ > you tend to worry. In the yaws case it seems like the problem is that it /o\ > does have a rebar.config and builds fine with rebar, but it does not > have its own copy of rebar locally which many packages seem to include > these days (or am I right, what is the norm?). So yaws is not built when > it is added as a dependency in an erlang.mk project. Right. [...] > So I guess the AUTOPATCH option in erlang.mk does not > seem to properly create a working Makefile. Yeah. That feature will currently fail when the rebar configuration uses hooks, scripts and such. It's good for 90% of projects but this one is too complex. > The way I always resolve this is to either copy in a rebar script into > the yaws folder or go through the autoconf procedure, which is the other > way of building yaws, but this is of course a manual process that I > would like to avoid. The problem is - which one is the odd one here - > should a fix be done in erlang.mk (perhaps in the > AUTOPATCH part) or should yaws' build system be fixed? Or should my two > friends continue to not get along properly forever and ever? :) Yaws is fine. Autotools support is something I have been meaning to add (both compiling projects that use autoconf and erlang.mk being usable in a larger autotools build environment). There are one or two projects I want to write plugins for that use autotools (I believe percept2 is one of them). Please add a ticket so I can look into it (I can't seem to be able to load Github this morning). I will work on an update this or next week so I could do it then. Cheers, -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Sun Mar 29 10:52:32 2015 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 29 Mar 2015 10:52:32 +0200 Subject: [erlang-questions] erlang.mk and yaws In-Reply-To: <5517B5BC.3060306@ninenines.eu> References: <5517B5BC.3060306@ninenines.eu> Message-ID: <5517BD50.6030105@ninenines.eu> Github is back. On 03/29/2015 10:20 AM, Lo?c Hoguin wrote: > want to write plugins for that use autotools (I believe percept2 is one > of them). That was not percept2. Not sure which one it was. > Please add a ticket so I can look into it (I can't seem to be able to > load Github this morning). I will work on an update this or next week so > I could do it then. https://github.com/ninenines/erlang.mk/issues/225 Enjoy! -- Lo?c Hoguin http://ninenines.eu From mmzeeman@REDACTED Sun Mar 29 11:06:21 2015 From: mmzeeman@REDACTED (Maas-Maarten Zeeman) Date: Sun, 29 Mar 2015 11:06:21 +0200 Subject: [erlang-questions] crypto EVP transition In-Reply-To: References: Message-ID: The openssl api documentations mentions this about using the low-level implementations. "Although low level algorithm specific functions exist for many algorithms their use is discouraged. They cannot be used with an ENGINE and ENGINE versions of new algorithms cannot be accessed using the low level functions. Also makes code harder to adapt to new algorithms and some options are not cleanly supported at the low level and some operations are more efficient using the high level interface.? and "All the symmetric algorithms (ciphers), digests and asymmetric algorithms (public key algorithms) can be replaced by ENGINE modules providing alternative implementations. If ENGINE implementations of ciphers or digests are registered as defaults, then the various EVP functions will automatically use those implementations automatically in preference to built in software implementations. For more information, consult the engine(3) man page.? AES-NI for openssl is an engine implementation, another example is VIA padlock or specialized hardware boards. By using the evp ?envelope? layer of openssl you can use all available ciphers in openssl and its engine implementations without adding new nif functions. To me that seems the most logical way to handle things. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sun Mar 29 22:49:36 2015 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 29 Mar 2015 22:49:36 +0200 Subject: [erlang-questions] erlang.mk and yaws In-Reply-To: References: Message-ID: <55186560.50503@wanadoo.fr> Le 29/03/2015 09:46, Stefan Hellkvist a ?crit : > Hi (long time lurker of this mailing list) > > I like erlang.mk and I like yaws and tend to use them > in various projects (big thank you to the respective contributors of > those projects). But when two of your friends do not get along together > you tend to worry. In the yaws case it seems like the problem is that it > does have a rebar.config and builds fine with rebar, but it does not > have its own copy of rebar locally which many packages seem to include > these days (or am I right, what is the norm?). So yaws is not built when > it is added as a dependency in an erlang.mk project. Hi, this may help, waiting for another solution from Lo?c : https://github.com/talentdeficit/erlang.fake thus needs however a rebar in path. regards From richard.youngkin@REDACTED Mon Mar 30 03:56:08 2015 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Sun, 29 Mar 2015 19:56:08 -0600 Subject: [erlang-questions] Erlang and Akka, The Sequel Message-ID: Hi all, First of all, my apologies for the long email. The subject is somewhat esoteric and therefore not easily expressed in a short email. I'm following up on this email thread [1] from a slightly different perspective. This time I'd like to focus on the abstractions supported by Erlang vs. Akka rather than questions regarding availability of skilled developers or the technical superiority of one VM vs. the other. Akka, on the surface, has first-class concepts that aren't supported by Erlang (e.g., Try, Future, Observable). By "first-class" I mean concepts/capabilities that are directly supported in the language and/or framework. For example, Erlang/OTP includes capabilities and concepts such as gen_server. Libraries (e.g., poolboy) address those that aren't available in Erlang/OTP. [2] almost addresses some of those questions, specifically Fred Hebert's and Garrett Smith's responses. Fred's response in [2] is interesting and informative, but it misses the mark in that it's up to the developer to know/understand how and when to implement the appropriate pattern. That's what capabilities such as gen_server are intended to eliminate. It gets even more interesting when discussing composable operations a la Akka. Here are 2 concepts in Akka that as far as I know aren't directly supported in Erlang. These only illustrate what's possible with the "Try" concept, but are also applicable to Future and Observable. 1. The concept that an operation might fail (i.e., the "Try" type in Akka). 2. Being able to easily compose operations that might fail in a way where the logic to detect and react to the failure can be expressed separately from the main logic path, aka the "happy path". Here's an example of the first (in Scala, taken from the Coursera course on Principles of Reactive Programming). It's simplistic, but I think it's applicable in more complicated use cases. Hopefully the Scala is pretty self-explanatory: 1 val coins: Try[List[Coin]] = adventure.collectCoins() 2 3 val treasure: Try[Treasure] = coins match { 4 case Success(cs) => adventure.buyTreasure(cs) 5 case failure @ Failure(t) => failure 6 } Basically what this is explicitly saying is that adventure.collectCoins() may fail and the success or failure of that operation can be used in the next operation which is to buy treasure using those coins. At this point this is just expressing the semantics of the operation directly in the code, namely that the operation may fail (as is also the case in buyTreasure). This isn't a programming error, it's just expressing that perhaps the adventure character couldn't collect coins and/or wasn't able to buy treasure (maybe they didn't have enough coins). So Erlang's "Let It Crash" philosophy isn't applicable. It can be argued that the block at lines 3-5 just a case expression, but this misses the point that the language directly expresses, through Try[], that both collectCoins() and buyTreasure can fail. The example above is interesting from a semantic perspective, but it's mixing the happy path with failure handling. This is where the next concept/capability of Akka is interesting, namely the ability to compose operations while separating the failure handling path from the "happy path". Here's the follow-on example from the same course: 1 val treasure: Try[Treasure] = 2 adventure.collectCoins().flatMap(coins => { 3 adventure.buyTreasure(coins) 4 }) 5 6 treasure match { 7 case Success(successValue) => 9 do something like continue to the next challenge... 10 case Failure(errorValue) => 11 do something like make the character repeat the previous challenge... So the "happy path" of collectCoins() and buyTreasure() isn't intermingled with what to do if one or both of these operations fail. Specifically, buyTreasure() won't throw an exception if collectCoins() fails. I don't know of any way to express this in Erlang. As far as I know Erlang doesn't support "Try" and the associated use of it in "match". In Akka this support is provided by monads. erlando is an Erlang library intended to provide monad support, but monads aren't baked into the language. And "Try" just applies to synchronous operations. "Future" implements the same semantics to async operations. "Observable" implements the same semantics to asynchronous stream operations. I don't have enough real-world experience in whether or not these concepts are encountered in day-to-day "reactive" programming in Erlang or Scala/Akka, but they do seem useful. This leads me to my questions: 1. Are these concepts generally useful or just interesting from an academic perspective? 2. Would it be useful to support these capabilities as first-class concepts in Erlang (similar to gen_servers)? Or is this so trivial in Erlang that it's not worth making these first class capabilities? 3. Is there any way to express these capabilities in Erlang (in addition to the rpc:async_call as described by Fred in [2], which only covers Futures, and doesn't support composition)? If there is I think a description of the pattern would be generally useful (Here's a plug for Garrett's new erlangpatterns.org). 4. Is there anything else significant to discuss about this? Thanks, Rich [1] http://erlang.org/pipermail/erlang-questions/2014-August/080699.html [2] http://erlang.org/pipermail/erlang-questions/2012-November/070679.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Mar 30 06:00:18 2015 From: ok@REDACTED (ok@REDACTED) Date: Mon, 30 Mar 2015 17:00:18 +1300 Subject: [erlang-questions] Erlang and Akka, The Sequel In-Reply-To: References: Message-ID: "Try" appears to be Haskell's "Maybe" monad, given a somewhat confusing name, with "flatMap" being the traditional "join :: Monad m => m (m x) -> m x". The Maybe monad is very close to the List monad; basically Nothing ~ [], Just x ~ [x]. And this leads immediately to how you can represent Try[X] in Erlang: as list(X), limited to at most 1 element. > 1 val coins: Try[List[Coin]] = adventure.collectCoins() > 2 > 3 val treasure: Try[Treasure] = coins match { > 4 case Success(cs) => adventure.buyTreasure(cs) > 5 case failure @ Failure(t) => failure > 6 } Coins = adventure:collect_coins(), Treasure = case Coins of [Cs] -> adventure:buy_treasure(Cs) ; Failure -> Failure end The "Failure(t)" bit shows that Try[t] is probably closer to Either String t. Either isn't a monad. > 1 val treasure: Try[Treasure] = > 2 adventure.collectCoins().flatMap(coins => { > 3 adventure.buyTreasure(coins) > 4 }) > 5 > 6 treasure match { > 7 case Success(successValue) => > 9 do something like continue to the next challenge... > 10 case Failure(errorValue) => > 11 do something like make the character repeat the previous > challenge... Coins = adventure:collect_coins(), Treasure = [adventure:buy_treasure(Cs) | Cs <- Coins], case Treasure of [Success_Value] -> ... ; [] -> ... end Your "happy path" then becomes Final_Result = [Z | A <- first_step(), B <- second_step(A), ..., Z <- last_step(Y)] > 1. Are these concepts generally useful or just interesting from an > academic perspective? Monads are pervasive in Haskell and tolerably comfortable there due to the essentially typed nature of Haskell. As soon as you have more than one monad to worry about (like IO + State + Error + ...) things can get messy. There is the Monad Transformer Library to help out, recently revised. Concepts may be generally useful and practical in one programming language but not another. Scala, for example, has this whole 'implicit' thing, so I suppose it can automatically convert a T to a Try[T] and vice versa when it's appropriate. Ada and ML, in contrast, do not. They are strongly typed, and get a lot of leverage from their type system, but don't have typeclasses. So they use exceptions. If you wanted to write code that was idiomatic maintainable Erlang, you'd want to keep it pretty straightforward and obvious. (As C.A.R.Hoare put it, "It is better that a program obviouslyhave no errors than have no obvious errors." To start with, you might want to make a clear distinction between errors and normal situations. For example, if you were doing some calculations with natural numbers, you might want a function least_proper_factor(N) Passing something that is not an integer is an error. Passing a negative number is an error. If the calculation encounters a divide-by-zero, that's an error. But there are lots of numbers that don't _have_ any proper factors, 1 for example. The other things are just plain not supposed to happen, but passing 1 or a prime is something you should think about handling. (Maybe the answer would be that that too counts as something that is just plain not supposed to happen; I only say you should *think* about that.) In an adventure game, there could be all sorts of reasons why trying to buy treasure with coins could fail: - there might not be enough - you might have collected East Slakan coins but the treasure's owner might only accept West Slakan coins (What, you didn't hear about the war in Slaka?) - your coins might be fairy gold - the coins might actually be little robots that shoot the treasure up and fly away - the vendor might swallow the coins and deny ever seeing them - your nannybot might decide that treasure isn't Good For You ... Considering all the things that could go wrong, expecting the program to handle them *and trying to hide the handling* does not seem like a good idea. In all discussions like this, a *real* is really important. > 2. Would it be useful to support these capabilities as first-class > concepts > in Erlang (similar to gen_servers)? I don't know what you mean by "first-class concepts". I certainly don't see gen_servers as first-class concepts in Erlang. They are a library, admittedly a very useful one, but basically not part of the *language*. > Or is this so trivial in Erlang that > it's not worth making these first class capabilities? Depending on the actual use case, it might be trivial, or it might be undesirable, or who knows what. > 3. Is there any way to express these capabilities in Erlang (in addition > to > the rpc:async_call as described by Fred in [2], which only covers Futures, > and doesn't support composition)? You've now changed the subject from Try to Futures. I think you may have misunderstood > [2] http://erlang.org/pipermail/erlang-questions/2012-November/070679.html Quoting my Smalltalk library, "Futures are not needed because joinable Processes *are* futures." ("Join" here referring to POSIX pthread_join(3).) The equivalent of a Future in Erlang is just a process. The only even slightly tricky bit is getting the result back. Here's the basic code: Key = self(), Pid = spawn(fun () -> Result = (the calculation), Key!{promise_reply, Result} end), ... receive {Pid, {promise_reply, Result}} -> ... end spawn(), !, and receive _are_ "first-class concepts". If we define future(Fun) when is_function(Fun, 0) -> Key = self(), {future, spawn(fun() -> Result = Fun(), Key!{promise_reply, Result} end)}. resolve({future, Pid}) when is_pid(Pid) -> receive {Pid, {promise_reply, Result}} -> Result end. then using a Future is just a matter of Future = future(fun () -> ... long computation ... end), ... Result = resolve(Future) It's not clear what you mean by saying that this doesn't support composition. I've expanded out what rpc:async and rpc:yield do to make the point that they don't do very much, and that if you want them to do something else, it's probably going to be pretty easy to do so using Erlang's native building blocks. (There's one thing that is a touch awkward about this. resolve/1 has to be called in the *same* process that called future/1. That's fairly easy to work around.) The thing is that nobody normally misses futures in Erlang because the things that people would use futures for are so easy to do directly with processes. The idea of handling futures by registering callbacks, as described in http://docs.scala-lang.org/overviews/core/futures.html, gives me the horrors. (Squeak Promises with their #whenResolved: give me similar horrors. I implemented them as a compatibility feature for my Smalltalk and rapidly realised that I never wanted to use them.) The preferred way to provide a result from one thread to another in Erlang is to *send a message*. From hellkvist@REDACTED Mon Mar 30 08:21:07 2015 From: hellkvist@REDACTED (Stefan Hellkvist) Date: Mon, 30 Mar 2015 08:21:07 +0200 Subject: [erlang-questions] erlang.mk and yaws In-Reply-To: <55186560.50503@wanadoo.fr> References: <55186560.50503@wanadoo.fr> Message-ID: > Hi, > > this may help, waiting for another solution from Lo?c : > > https://github.com/talentdeficit/erlang.fake > > thus needs however a rebar in path. > Thanks! Yes, such a wrapper helps building dependencies that have a rebar.config but no rebar script. However, the amount of work to copy the Makefile to the deps folder in question is about equivalent to a "cd" to the deps folder and a "rebar compile" so it does not get us to the point where no manual intervention is needed unfortunately. You have no control over the dependency projects and you cannot force this Makefile into the git repository of those projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.pic@REDACTED Mon Mar 30 12:24:21 2015 From: harsha.pic@REDACTED (harsha sri) Date: Mon, 30 Mar 2015 15:54:21 +0530 Subject: [erlang-questions] Stopping Application in erlang. Message-ID: Hi, I am running appication with Supervisor & Worker model. Can anybody guide me through how to stop application or restart my application. Below is my application file: -module(uclient). -behaviour(application). -export([start/2, stop/1]). -record(state, {pid}). start(normal, []) -> case uclient_sup:start_link({uclient_sup}) of {ok, Pid} -> {ok, Pid}; Error -> Error end. %%uclient_sup:start_link({uclient_sup}). stop(_State) -> ok. Tried to stop application from erl command line, but getting error as below: uclient:stop(). ** exception error: undefined function uclient:stop/0 Regards, Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From radek@REDACTED Mon Mar 30 12:27:06 2015 From: radek@REDACTED (Rad Gruchalski) Date: Mon, 30 Mar 2015 12:27:06 +0200 Subject: [erlang-questions] Stopping Application in erlang. In-Reply-To: References: Message-ID: <8B35B08C38DA4760AB596FCCC4A3C30A@gruchalski.com> Obviously, you export stop/1 and the error tells you stop/0 is undefined. Call it as uclient:stop(normal) and you?ll get an ok back. Kind regards, Radek Gruchalski radek@REDACTED (mailto:radek@REDACTED) (mailto:radek@REDACTED) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Monday, 30 March 2015 at 12:24, harsha sri wrote: > Hi, > > I am running appication with Supervisor & Worker model. > Can anybody guide me through how to stop application or restart my application. > > Below is my application file: > > -module(uclient). > > -behaviour(application). > > -export([start/2, stop/1]). > > -record(state, {pid}). > > start(normal, []) -> > case uclient_sup:start_link({uclient_sup}) of > {ok, Pid} -> {ok, Pid}; > Error -> Error > end. > %%uclient_sup:start_link({uclient_sup}). > > stop(_State) -> > ok. > > > > Tried to stop application from erl command line, but getting error as below: > > uclient:stop(). > ** exception error: undefined function uclient:stop/0 > > Regards, > Harsha > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailparmalat@REDACTED Mon Mar 30 12:35:14 2015 From: mailparmalat@REDACTED (Steven) Date: Mon, 30 Mar 2015 12:35:14 +0200 Subject: [erlang-questions] Cannot allocate heap - who is the culprit? Message-ID: Hi all, If a crashdump is produced and indicates that it cannot allocate XXXXXXXX bytes of type heap memory (or old heap), is there a way to find out, from the crashdump file, which process is trying to request memory? Regards, Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Mon Mar 30 12:37:06 2015 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Mon, 30 Mar 2015 12:37:06 +0200 Subject: [erlang-questions] erlang.mk and yaws Message-ID: <2a7d0b14e8c376bd2fc5bd51aa142895@mwinf5d23.me-wanadoo.net> An HTML attachment was scrubbed... URL: From magnus@REDACTED Mon Mar 30 12:49:46 2015 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 30 Mar 2015 11:49:46 +0100 Subject: [erlang-questions] Stopping Application in erlang. In-Reply-To: (harsha sri's message of "Mon, 30 Mar 2015 15:54:21 +0530") References: Message-ID: harsha sri writes: > I am running appication with Supervisor & Worker model. Can > anybody guide me through how to stop application or restart my > application. > > Below is my application file: > > -module(uclient). > > -behaviour(application). > > -export([start/2, stop/1]). > > -record(state, {pid}). > > start(normal, []) -> > case uclient_sup:start_link({uclient_sup}) of > {ok, Pid} -> {ok, Pid}; > Error -> Error > end. > %%uclient_sup:start_link({uclient_sup}). > > stop(_State) -> > ok. > > > Tried to stop application from erl command line, but getting > error as below: > > uclient:stop(). > ** exception error: undefined function uclient:stop/0 The function uclient:stop/1 in your application module is just a callback module, that is supposed to do any application-specific cleanup before the application is stopped. In most cases, it will look just like yours in the example above: it does nothing. The real work of stopping an application is stopping the supervision tree and all the linked processes. For that, you need application:stop/1: application:stop(uclient). Regards, Magnus From harsha.pic@REDACTED Mon Mar 30 13:08:45 2015 From: harsha.pic@REDACTED (harsha sri) Date: Mon, 30 Mar 2015 16:38:45 +0530 Subject: [erlang-questions] Stopping Application in erlang. In-Reply-To: <8B35B08C38DA4760AB596FCCC4A3C30A@gruchalski.com> References: <8B35B08C38DA4760AB596FCCC4A3C30A@gruchalski.com> Message-ID: Hi Rad, Tried with, seems same error: uclient:stop(normal). ** exception error: undefined function uclient:stop/1 Regards, Harsha On Mon, Mar 30, 2015 at 3:57 PM, Rad Gruchalski wrote: > Obviously, you export stop/1 and the error tells you stop/0 is undefined. > Call it as > > uclient:stop(normal) and you?ll get an ok back. > > Kind regards, > Radek Gruchalski > radek@REDACTED > de.linkedin.com/in/radgruchalski/ > > > *Confidentiality:*This communication is intended for the above-named > person and may be confidential and/or legally privileged. > If it has come to you in error you must take no action based on it, nor > must you copy or show it to anyone; please delete/destroy and inform the > sender immediately. > > On Monday, 30 March 2015 at 12:24, harsha sri wrote: > > Hi, > > I am running appication with Supervisor & Worker model. > Can anybody guide me through how to stop application or restart my > application. > > Below is my application file: > > -module(uclient). > > -behaviour(application). > > -export([start/2, stop/1]). > > -record(state, {pid}). > > start(normal, []) -> > case uclient_sup:start_link({uclient_sup}) of > {ok, Pid} -> {ok, Pid}; > Error -> Error > end. > %%uclient_sup:start_link({uclient_sup}). > > stop(_State) -> > ok. > > > > Tried to stop application from erl command line, but getting error as > below: > > uclient:stop(). > ** exception error: undefined function uclient:stop/0 > > Regards, > Harsha > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.pic@REDACTED Mon Mar 30 13:11:44 2015 From: harsha.pic@REDACTED (harsha sri) Date: Mon, 30 Mar 2015 16:41:44 +0530 Subject: [erlang-questions] Stopping Application in erlang. In-Reply-To: References: Message-ID: Hi Magnus, Tried application:stop, giving me error: application:stop(uclient). {error,{not_started,uclient}} Actually application got started and its running also. This application i am running ad rabbitmq plugin and its running also, only thing i need to stop my application and restart application which i am not able to do. Regards, Harsha. On Mon, Mar 30, 2015 at 4:19 PM, Magnus Henoch wrote: > harsha sri writes: > > I am running appication with Supervisor & Worker model. Can anybody >> guide me through how to stop application or restart my application. >> >> Below is my application file: >> >> -module(uclient). >> >> -behaviour(application). >> >> -export([start/2, stop/1]). >> >> -record(state, {pid}). >> >> start(normal, []) -> >> case uclient_sup:start_link({uclient_sup}) of >> {ok, Pid} -> {ok, Pid}; >> Error -> Error >> end. >> %%uclient_sup:start_link({uclient_sup}). >> >> stop(_State) -> >> ok. >> >> Tried to stop application from erl command line, but getting error as >> below: >> >> uclient:stop(). >> ** exception error: undefined function uclient:stop/0 >> > > The function uclient:stop/1 in your application module is just a callback > module, that is supposed to do any application-specific cleanup before the > application is stopped. In most cases, it will look just like yours in the > example above: it does nothing. > > The real work of stopping an application is stopping the supervision tree > and all the linked processes. For that, you need application:stop/1: > > application:stop(uclient). > > Regards, > Magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.widgren@REDACTED Mon Mar 30 14:12:18 2015 From: daniel.widgren@REDACTED (Daniel Hallin Widgren) Date: Mon, 30 Mar 2015 14:12:18 +0200 Subject: [erlang-questions] Stopping Application in erlang. In-Reply-To: References: Message-ID: Can it be so that your application is named something else? How is your .app file? Can you see your application if you run application:which_applications()? Den 30 mar 2015 13:12 skrev "harsha sri" : > Hi Magnus, > > Tried application:stop, giving me error: > > application:stop(uclient). > {error,{not_started,uclient}} > > Actually application got started and its running also. This application i > am running ad rabbitmq plugin and its running also, only thing i need to > stop my application and restart application which i am not able to do. > > Regards, > Harsha. > > On Mon, Mar 30, 2015 at 4:19 PM, Magnus Henoch < > magnus@REDACTED> wrote: > >> harsha sri writes: >> >> I am running appication with Supervisor & Worker model. Can anybody >>> guide me through how to stop application or restart my application. >>> >>> Below is my application file: >>> >>> -module(uclient). >>> >>> -behaviour(application). >>> >>> -export([start/2, stop/1]). >>> >>> -record(state, {pid}). >>> >>> start(normal, []) -> >>> case uclient_sup:start_link({uclient_sup}) of >>> {ok, Pid} -> {ok, Pid}; >>> Error -> Error >>> end. >>> %%uclient_sup:start_link({uclient_sup}). >>> >>> stop(_State) -> >>> ok. >>> >>> Tried to stop application from erl command line, but getting error as >>> below: >>> >>> uclient:stop(). >>> ** exception error: undefined function uclient:stop/0 >>> >> >> The function uclient:stop/1 in your application module is just a callback >> module, that is supposed to do any application-specific cleanup before the >> application is stopped. In most cases, it will look just like yours in the >> example above: it does nothing. >> >> The real work of stopping an application is stopping the supervision tree >> and all the linked processes. For that, you need application:stop/1: >> >> application:stop(uclient). >> >> Regards, >> Magnus >> > > > _______________________________________________ > 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 30 15:39:21 2015 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 30 Mar 2015 09:39:21 -0400 Subject: [erlang-questions] Erlang and Akka, The Sequel In-Reply-To: References: Message-ID: <20150330133920.GA75677@ferdair.local> On 03/29, Youngkin, Rich wrote: >Fred's response in [2] is interesting and informative, but it misses >the mark in that it's up to the developer to know/understand how and >when to implement the appropriate pattern. That's what capabilities >such as gen_server are intended to eliminate. I'm not sure I understand the criticism there. [2] was about using RPC/futures, and the answer shows how to use RPC/futures. Also there is *no replacement* to know when to use the appropriate pattern. I'm not sure of the intended wording here, if you meant "implement" as build the pattern from scratch, or "implement" as using the pattern. I went here with the latter interpretation, but do know that for futures, there is nothing else to do in Erlang than the example in my response to the initial post. Let's use the Akka example (from http://doc.akka.io/docs/akka/snapshot/java/futures.html): Timeout timeout = new Timeout(Duration.create(5, "seconds")); Future future = Patterns.ask(actor, msg, timeout); String result = (String) Await.result(future, timeout.durtion()) Think of the following usage in Erlang: Timeout = timer:seconds(5000), Future = rpc:async_call(node(), Mod, call, [Actor, Msg, [Timeout]), {ok, Result} = rpc:nb_yield(Future, Timeout). They are semantically equivalent. The only thing tricky about Erlang is to find it in the RPC module. >1. The concept that an operation might fail (i.e., the "Try" type in >Akka). It appears that `Try` is a type in Scala, not Akka. I went to http://helenaedelson.com/?p=939 and http://www.scala-lang.org/files/archive/nightly/docs/library/index.html#scala.util.Try to try to figure out what they are. Those appear to be your standard 'either' type, and 'match' in the following example looks a bit like a 'maybe' monad, but I'll get on that later to avoid reordering the quotes of your email. >2. Being able to easily compose operations that might fail in a way where >the logic to detect and react to the failure can be expressed separately >from the main logic path, aka the "happy path". > That does sound a lot like 'let it crash', but I'm guessing the point here is due to the cumbersome level of `{ok, Value}` vs. any other value to represent successes vs. errors (i.e. moving from an Either type to also passing them to a Maybe monad) >Here's an example of the first (in Scala, taken from the Coursera course on >Principles of Reactive Programming). It's simplistic, but I think it's >applicable in more complicated use cases. Hopefully the Scala is pretty >self-explanatory: > >1 val coins: Try[List[Coin]] = adventure.collectCoins() >2 >3 val treasure: Try[Treasure] = coins match { >4 case Success(cs) => adventure.buyTreasure(cs) >5 case failure @ Failure(t) => failure >6 } >Basically what this is explicitly saying is that >adventure.collectCoins() >may fail and the success or failure of that operation can be used in the >next operation which is to buy treasure using those coins. At this point >this is just expressing the semantics of the operation directly in the >code, namely that the operation may fail (as is also the case in >buyTreasure). This isn't a programming error, it's just expressing that >perhaps the adventure character couldn't collect coins and/or wasn't able >to buy treasure (maybe they didn't have enough coins). So Erlang's "Let It >Crash" philosophy isn't applicable. It can be argued that the block at >lines 3-5 just a case expression, but this misses the point that the >language directly expresses, through Try[], that both collectCoins() and >buyTreasure can fail. Right, so this could be: Coins = adventure:collect_coins(), Treasure = case Coins of {ok, Cs} -> adventure:buy_treasure(Cs); Error -> Error % or should it be thrown? end But this does look like a regular `case` expression, and I'm guessing the example of composability would need more complexity to better show what you mean. I am not ready to say that 'Let it crash' doesn't apply. You can very well let it crash there, but this is a question that depends on whether you decide to or not, and what you might need to report to the user. > >The example above is interesting from a semantic perspective, but it's >mixing the happy path with failure handling. This is where the next >concept/capability of Akka is interesting, namely the ability to compose >operations while separating the failure handling path from the "happy >path". Here's the follow-on example from the same course: > This is where a difference is made with these types/monads, yes! >1 val treasure: Try[Treasure] = >2 adventure.collectCoins().flatMap(coins => { >3 adventure.buyTreasure(coins) >4 }) >5 >6 treasure match { >7 case Success(successValue) => >9 do something like continue to the next challenge... >10 case Failure(errorValue) => >11 do something like make the character repeat the previous challenge... > >So the "happy path" of collectCoins() and buyTreasure() isn't intermingled >with what to do if one or both of these operations fail. Specifically, >buyTreasure() won't throw an exception if collectCoins() fails. I don't >know of any way to express this in Erlang. Yes. So the regular `try .. catch` attempt would be: try {ok, Cs} = adventure:collect_coins(), Res = lists:flatmap(fun(Coins) -> {ok, Val} = adventure:buy_treasure(Coins), Val end, Cs), of SuccessValue -> %% Do something like continue to next challenge catch Type:Reason -> %% Do something like maybe repeat the previous challenge end. Given what we care about here is whether we actually failed *anywhere* or *nowhere* (at least based on your failure value match), this is equivalent to what you have. Interestingly, because you could be expected to see each operation fail, you might also have a callee go for harder failures: try lists:flatmap(fun(Coins) -> adventure:buy_treasure(Coins) end, adventure:collect_coins()) of SuccessValue -> % Keep going catch _:_ -> % alt path end The distinction is there, and really, the challenge is picking which one to implement when you design the 'adventure' module. I'd argue for the former if you expect multiple operations to 'fail' (it is likely that a character cannot connect coins without it being a programmer error), so that the caller can choose how to handle alternative branches at every level. The cumbersome alternative is to indeed bake in the flow control to the values, yielding things like: handle_coins() -> case collect() of {ok, Val} -> % keep going Error -> % error path end. collect() -> case adventure:collect_coins() of {ok, Coins} -> buy_treasure(Coins); Error -> Error end. buy_treasure() -> %% and so on It's one we do actually see a lot in Erlang overall, especially if you end up wanting specific handling of alternative result at each level (logging a message, storing metrics, returning a failed value, undoing operations, backoff, whatever) which could be harder to do at one end or the other. > >As far as I know Erlang doesn't support "Try" and the associated use of it >in "match". In Akka this support is provided by monads. erlando is an >Erlang library intended to provide monad support, but monads aren't baked >into the language. And "Try" just applies to synchronous operations. >"Future" implements the same semantics to async operations. "Observable" >implements the same semantics to asynchronous stream operations. > Right. >I don't have enough real-world experience in whether or not these concepts >are encountered in day-to-day "reactive" programming in Erlang or >Scala/Akka, but they do seem useful. This leads me to my questions: > >1. Are these concepts generally useful or just interesting from an academic >perspective? They are truly useful in my opinion, but how needed they are may depend on what exception handling mechanism you have. Erlang does tend to have that pattern made explicit with sequences of case expression (as in my last example). Whether this is boilerplate that ought to be eliminated is likely a question of personal preferences. >2. Would it be useful to support these capabilities as first-class concepts >in Erlang (similar to gen_servers)? Or is this so trivial in Erlang that >it's not worth making these first class capabilities? This is a more interesting question, because Erlang does have a lot of ways to handle exceptions. I mean you can have actual exceptions, option types, tagged values, multiple return values, signals, continuations, mixes of them, and so on. Mahesh Paolini-Subramanya, in one of his Erlang factories presentations (see http://www.erlang-factory.com/conference/Chicago2013/speakers/MaheshPaoliniSubramanya), defined the following concerns when handling failures in order to get fault tolerance: 1. Separation of Concerns (Each people can be treated individually) 2. Error Encapsulation (The infection doesn't spread) 3. Fault Detection (Make sure you know someone is infected) 4. Fault Identification (You have got this specific strain of flu!) Separation of concerns os usually given by having each process entirely isolated in Erlang, and tends to compose well with Error Encapsulation. What is interesting is that error encapsulation is invariably best done at the lowest level of abstraction possible (this is what isolates an error the most from the rest of the system!); conversely, fault detection and identification tend to get broken by this approach -- if you eat up errors, you never know what they properly are. This is the dreaded 'try ... catch' that catches everything and returns 'ok' as if everything was fine. So to me the question is not necessarily whether it's worth making a first-class capability out of it, but whether adding it would help in any of these cases. For example, one of the very interesting form we see in a production proxy here is the following form: relay(Client, Server) -> case read(Client) of done -> {ok, Client, Server}; {ok, Data} -> send(Client, Server, Data); {error, Reason} -> {error, upstream, Reason} end. send(Client, Server, Data) -> case gen_tcp:send(Server#server.port, Data) of ok -> relay(Client, add_metrics(Server, Data)); {error, Reason} -> {error, downstream, Reason} end. Now the actual code is more complex than this (lots more funnier cases with buffering and error-detection) This kind of mechanism is nice to have because it helps in all cases: 1. Obtained through individual processes 2. An error interrupts the flow ASAP and tells you *why* 3. The error condition bubbles up as a well known tuple (and we also take care of identifying good terminations) 4. We know specifically why a condition failed, and whether it was due to the client or the server, which turns out to be critical when relaying the information to customers. So for me the question is rather whether option types / Either types / maybe monads retain the necessary flexibility. If the semantics of the maybe monad end up similar, to say: relay(Client, Server) -> case read(Client) of done -> {ok, Client, Server}; {ok, Data} -> ok = gen_tcp:send(Server#server.port, Data), relay(Client, add_metrics(Server, Data)) end. Meaning that we just fail and lose contextual data when it happens, then I, as a programmer, may not get much in terms of expressiveness outside of not relying on exceptions. In this case, I'd say the benefit is minor at best and let-it-crash (with an optional try ... catch) is still good enough for pretty much all intents and purposes. I get a similar result (happy path, exceptions/branches may lose some contextual data, apparent composability, etc.) From harsha.pic@REDACTED Mon Mar 30 17:10:50 2015 From: harsha.pic@REDACTED (harsha sri) Date: Mon, 30 Mar 2015 20:40:50 +0530 Subject: [erlang-questions] Stopping Application in erlang. In-Reply-To: References: Message-ID: Hi Daniel, This is my uclient.app.src: {application, uclient, [{description, "UC Client Plugin for Provisioning ontot callmanager"}, {vsn, "%%VSN%%"}, {modules, []}, {id, "uclient"}, {registered, [uclient]}, {mod, {uclient, []}}, {env, []}, {applications, [kernel, stdlib, rabbit, amqp_client]}]}. Regards, Harsha On Mon, Mar 30, 2015 at 5:42 PM, Daniel Hallin Widgren < daniel.widgren@REDACTED> wrote: > Can it be so that your application is named something else? > > How is your .app file? > > Can you see your application if you run application:which_applications()? > Den 30 mar 2015 13:12 skrev "harsha sri" : > >> Hi Magnus, >> >> Tried application:stop, giving me error: >> >> application:stop(uclient). >> {error,{not_started,uclient}} >> >> Actually application got started and its running also. This application i >> am running ad rabbitmq plugin and its running also, only thing i need to >> stop my application and restart application which i am not able to do. >> >> Regards, >> Harsha. >> >> On Mon, Mar 30, 2015 at 4:19 PM, Magnus Henoch < >> magnus@REDACTED> wrote: >> >>> harsha sri writes: >>> >>> I am running appication with Supervisor & Worker model. Can anybody >>>> guide me through how to stop application or restart my application. >>>> >>>> Below is my application file: >>>> >>>> -module(uclient). >>>> >>>> -behaviour(application). >>>> >>>> -export([start/2, stop/1]). >>>> >>>> -record(state, {pid}). >>>> >>>> start(normal, []) -> >>>> case uclient_sup:start_link({uclient_sup}) of >>>> {ok, Pid} -> {ok, Pid}; >>>> Error -> Error >>>> end. >>>> %%uclient_sup:start_link({uclient_sup}). >>>> >>>> stop(_State) -> >>>> ok. >>>> >>>> Tried to stop application from erl command line, but getting error as >>>> below: >>>> >>>> uclient:stop(). >>>> ** exception error: undefined function uclient:stop/0 >>>> >>> >>> The function uclient:stop/1 in your application module is just a >>> callback module, that is supposed to do any application-specific cleanup >>> before the application is stopped. In most cases, it will look just like >>> yours in the example above: it does nothing. >>> >>> The real work of stopping an application is stopping the supervision >>> tree and all the linked processes. For that, you need application:stop/1: >>> >>> application:stop(uclient). >>> >>> Regards, >>> Magnus >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.widgren@REDACTED Mon Mar 30 18:43:04 2015 From: daniel.widgren@REDACTED (Daniel Hallin Widgren) Date: Mon, 30 Mar 2015 18:43:04 +0200 Subject: [erlang-questions] Stopping Application in erlang. In-Reply-To: References: Message-ID: Have you tried: Application:start(uclient). Application:stop(uclient). Den 30 mar 2015 17:11 skrev "harsha sri" : > Hi Daniel, > > This is my uclient.app.src: > > {application, uclient, > [{description, "UC Client Plugin for Provisioning ontot callmanager"}, > {vsn, "%%VSN%%"}, > {modules, []}, > {id, "uclient"}, > {registered, [uclient]}, > {mod, {uclient, []}}, > {env, []}, > {applications, [kernel, stdlib, rabbit, amqp_client]}]}. > > Regards, > Harsha > > On Mon, Mar 30, 2015 at 5:42 PM, Daniel Hallin Widgren < > daniel.widgren@REDACTED> wrote: > >> Can it be so that your application is named something else? >> >> How is your .app file? >> >> Can you see your application if you run application:which_applications()? >> Den 30 mar 2015 13:12 skrev "harsha sri" : >> >>> Hi Magnus, >>> >>> Tried application:stop, giving me error: >>> >>> application:stop(uclient). >>> {error,{not_started,uclient}} >>> >>> Actually application got started and its running also. This application >>> i am running ad rabbitmq plugin and its running also, only thing i need to >>> stop my application and restart application which i am not able to do. >>> >>> Regards, >>> Harsha. >>> >>> On Mon, Mar 30, 2015 at 4:19 PM, Magnus Henoch < >>> magnus@REDACTED> wrote: >>> >>>> harsha sri writes: >>>> >>>> I am running appication with Supervisor & Worker model. Can anybody >>>>> guide me through how to stop application or restart my application. >>>>> >>>>> Below is my application file: >>>>> >>>>> -module(uclient). >>>>> >>>>> -behaviour(application). >>>>> >>>>> -export([start/2, stop/1]). >>>>> >>>>> -record(state, {pid}). >>>>> >>>>> start(normal, []) -> >>>>> case uclient_sup:start_link({uclient_sup}) of >>>>> {ok, Pid} -> {ok, Pid}; >>>>> Error -> Error >>>>> end. >>>>> %%uclient_sup:start_link({uclient_sup}). >>>>> >>>>> stop(_State) -> >>>>> ok. >>>>> >>>>> Tried to stop application from erl command line, but getting error as >>>>> below: >>>>> >>>>> uclient:stop(). >>>>> ** exception error: undefined function uclient:stop/0 >>>>> >>>> >>>> The function uclient:stop/1 in your application module is just a >>>> callback module, that is supposed to do any application-specific cleanup >>>> before the application is stopped. In most cases, it will look just like >>>> yours in the example above: it does nothing. >>>> >>>> The real work of stopping an application is stopping the supervision >>>> tree and all the linked processes. For that, you need application:stop/1: >>>> >>>> application:stop(uclient). >>>> >>>> Regards, >>>> Magnus >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Tue Mar 31 04:50:10 2015 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Mon, 30 Mar 2015 21:50:10 -0500 Subject: [erlang-questions] Cannot allocate heap - who is the culprit? In-Reply-To: Message of "Mon, 30 Mar 2015 12:35:14 +0200." Message-ID: <15603.1427770210@snookles.snookles.com> Steven wrote: s> Hi all, If a crashdump is produced and indicates that it cannot s> allocate XXXXXXXX bytes of type heap memory (or old heap), is there a s> way to find out, from the crashdump file, which process is trying to s> request memory? When looking at the 'erl_crash.dump' file (as plain text or in the Crashdump Viewer application), it's almost always the process that's in the 'Garbing' state, namely it's in the middle of a garbage collection (GC) operation. -Scott From mailparmalat@REDACTED Tue Mar 31 08:39:41 2015 From: mailparmalat@REDACTED (Steven) Date: Tue, 31 Mar 2015 08:39:41 +0200 Subject: [erlang-questions] Cannot allocate heap - who is the culprit? In-Reply-To: <15603.1427770210@snookles.snookles.com> References: <15603.1427770210@snookles.snookles.com> Message-ID: Thanks, that makes sense Regards, Steven On Tue, Mar 31, 2015 at 4:50 AM, Scott Lystig Fritchie < fritchie@REDACTED> wrote: > Steven wrote: > > s> Hi all, If a crashdump is produced and indicates that it cannot > s> allocate XXXXXXXX bytes of type heap memory (or old heap), is there a > s> way to find out, from the crashdump file, which process is trying to > s> request memory? > > When looking at the 'erl_crash.dump' file (as plain text or in the > Crashdump Viewer application), it's almost always the process that's in > the 'Garbing' state, namely it's in the middle of a garbage collection > (GC) operation. > > -Scott > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.pic@REDACTED Tue Mar 31 15:20:18 2015 From: harsha.pic@REDACTED (harsha sri) Date: Tue, 31 Mar 2015 18:50:18 +0530 Subject: [erlang-questions] Erlang Application(Supervisor/Worker) - Stopping Application Message-ID: Hi, I created erlang application which is Supervisor/Worker model, Dynamically based on input xml Supervisor will creates so many workers. If i want to restart my application, how to kill associated children and Supervior by calling application:stop(name). Application: -module(uclient). -behaviour(application). -export([start/2, stop/1]). start(normal,[]) -> case uclient_sup:start_link({uclient_sup}) of {ok, Pid} -> {ok, Pid}; Error -> Error end. stop(_State) -> ok. Basically i need to terminate all children associated to this application. How can i do this? please suggest me. Any references please let me know. Regards, Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From varjaofilipe@REDACTED Tue Mar 31 15:08:41 2015 From: varjaofilipe@REDACTED (=?UTF-8?Q?Filipe_Varj=C3=A3o?=) Date: Tue, 31 Mar 2015 10:08:41 -0300 Subject: [erlang-questions] Erlang EdisonAPI Message-ID: Hi folks, I would like to ask if we have some library/API in Erlang like the EdisonApi for Haskell ? Thanks []s Let it crash! -------------- next part -------------- An HTML attachment was scrubbed... URL: