From ivan@REDACTED Tue Oct 1 15:17:07 2013 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 01 Oct 2013 14:17:07 +0100 Subject: [erlang-questions] EBU Networked Media Taskforce Request for Technology Message-ID: <524ACB53.6070305@llaisdy.com> Dear All Sorry if this is off-topic and/or old news. Thought it might be interesting for erlangers working on media technology. The European Broadcasting Union Joint Task Force on Networked Media has put out a Request for Technology: The opportunity to build future production environments that are solely based on IT infrastructure and packet networks (Ethernet, IP, etc.), rather than speciality broadcast equipment and interfaces (SDI, AES, etc.), offers new ways to produce content. It could facilitate new workflow possibilities, increased production efficiency, increased multiscreen programme output and cost reductions. The Task Force has published its RFT - on 12 September 2013 - with the goal of identifying the technologies, current or in development, which can fulfil the business-driven user requirements that were collected in the first phase of the Task Force's work. The RfT and the preceding user requirements doc are available as pdfs from the JT-NM page. Press release (with link to JT-NM page): http://tech.ebu.ch/news/technologies-requested-by-the-jt-nm-12sep13 (disclaimer: I am not involved with the EBU other than reading their newsletters) Best wishes Ivan -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From jon@REDACTED Wed Oct 2 11:04:06 2013 From: jon@REDACTED (Jon Schneider) Date: Wed, 2 Oct 2013 10:04:06 +0100 Subject: [erlang-questions] config files Message-ID: <2e532de8d21d99ca7cd1f72357d27b81.squirrel@mail.jschneider.net> I'm trying to influence the choice of TCP port of a node (behind firewall etc.) so. I can application:set_env(kernel, inet_dist_listen_min, 9000), application:set_env(kernel, inet_dist_listen_max, 9005), and that does the right thing. But if I write a config file then invoke erl with the -config option I get C:\Program Files\erl5.10.2\bin>erl -config jon {"could not start kernel pid",application_controller,"invalid config data: invalid application name: kernel"} where jon.config says [kernel, [{inet_dist_listen_min, 9000}, {inet_dist_listen_max, 9005} ]]. Isn't kernel an application name ? Or what is the nice way to do this ? Incidentally at http://www.erlang.org/doc/man/config.html under sys.config a closing square bracket is missing in the first code snippet. Jon From essen@REDACTED Wed Oct 2 11:25:18 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 02 Oct 2013 11:25:18 +0200 Subject: [erlang-questions] config files In-Reply-To: <2e532de8d21d99ca7cd1f72357d27b81.squirrel@mail.jschneider.net> References: <2e532de8d21d99ca7cd1f72357d27b81.squirrel@mail.jschneider.net> Message-ID: <524BE67E.4000204@ninenines.eu> On 10/02/2013 11:04 AM, Jon Schneider wrote: > [kernel, [{inet_dist_listen_min, 9000}, {inet_dist_listen_max, 9005} ]]. Try: [{kernel, [{inet_dist_listen_min, 9000}, {inet_dist_listen_max, 9005} ]}]. > Isn't kernel an application name ? > > Or what is the nice way to do this ? > > Incidentally at http://www.erlang.org/doc/man/config.html under sys.config > a closing square bracket is missing in the first code snippet. > > Jon > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From pierrefenoll@REDACTED Wed Oct 2 16:03:28 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Wed, 2 Oct 2013 15:03:28 +0100 Subject: [erlang-questions] Fwd: erldocs.com updated! In-Reply-To: References: Message-ID: Hi, http://erldocs.com is a fast and accessible alternative to the official Erlang/OTP documentation. Originally developed by Dale Harvey, it was no longer supported since the release of R15B. I recently took over erldocs.com and the erldocs GitHub project, fixed some issues and compiled documentation for all Erlang/OTP versions. The website is now hosted on GitHub gh-pages as it is only static files (thank you GitHub, that's amazing!) and back on tracks! Go check another Erlang doc at http://erldocs.com/ Go check the code at https://github.com/fenollp/erldocs Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ola.Backstrom@REDACTED Wed Oct 2 16:33:25 2013 From: Ola.Backstrom@REDACTED (=?utf-8?B?T2xhICBCw6Rja3N0csO2bQ==?=) Date: Wed, 2 Oct 2013 14:33:25 +0000 Subject: [erlang-questions] Fwd: erldocs.com updated! In-Reply-To: References: Message-ID: Excellent news, Thanks Pierre for your work to keep erldocs updated, it is one of my top-10 links! A question, is there a reason for the documentation of newer Erlang/OTP versions not to provide type information? For instance R14B02 do provide that, in yellow boxes. Compare http://erldocs.com/R14B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 with http://erldocs.com/R16B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 The first link shows that the function argument should be of type gb_tree() but the latter not. /Ola From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Pierre Fenoll Sent: den 2 oktober 2013 16:03 To: erlang-questions@REDACTED Questions Subject: [erlang-questions] Fwd: erldocs.com updated! Hi, http://erldocs.com is a fast and accessible alternative to the official Erlang/OTP documentation. Originally developed by Dale Harvey, it was no longer supported since the release of R15B. I recently took over erldocs.com and the erldocs GitHub project, fixed some issues and compiled documentation for all Erlang/OTP versions. The website is now hosted on GitHub gh-pages as it is only static files (thank you GitHub, that's amazing!) and back on tracks! Go check another Erlang doc at http://erldocs.com/ Go check the code at https://github.com/fenollp/erldocs Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Wed Oct 2 16:52:01 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Wed, 2 Oct 2013 15:52:01 +0100 Subject: [erlang-questions] Fwd: erldocs.com updated! In-Reply-To: References: Message-ID: Hey Ola, `diff -y otp_src_R1{4,6}B02/lib/stdlib/doc/src/gb_trees.xml | less` shows that type information (and argument names) were removed moving from R14B02 to R16B02. Maybe someone can hint to where this information was moved? as I hope^Wbelieve it didn't just got trashed. erldocs only provides a different compiled documentation. The source files are still just those found under doc/src/*.xml and maintained by Ericsson/the community. Sorry but you (well, we both) will have to s/R16/R14/ the URL for now? Cheers, -- Pierre Fenoll On 2 October 2013 15:33, Ola B?ckstr?m wrote: > Excellent news,**** > > ** ** > > Thanks Pierre for your work to keep erldocs updated, it is one of my > top-10 links!**** > > ** ** > > A question, is there a reason for the documentation of newer Erlang/OTP > versions not to provide type information? **** > > For instance R14B02 do provide that, in yellow boxes. Compare**** > > **** > > > http://erldocs.com/R14B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 > **** > > with**** > > > http://erldocs.com/R16B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 > **** > > ** ** > > The first link shows that the function argument should be of type > gb_tree() but the latter not.**** > > ** ** > > /Ola**** > > ** ** > > *From:* erlang-questions-bounces@REDACTED [mailto: > erlang-questions-bounces@REDACTED] *On Behalf Of *Pierre Fenoll > *Sent:* den 2 oktober 2013 16:03 > *To:* erlang-questions@REDACTED Questions > *Subject:* [erlang-questions] Fwd: erldocs.com updated!**** > > ** ** > > Hi,**** > > ** ** > > http://erldocs.com is a fast and accessible alternative to the official > Erlang/OTP documentation.**** > > Originally developed by Dale Harvey, it was no longer supported since the > release of R15B.**** > > ** ** > > I recently took over erldocs.com and the erldocs GitHub project, fixed > some issues and compiled documentation for all Erlang/OTP versions. The > website is now hosted on GitHub gh-pages as it is only static files (thank > you GitHub, that's amazing!) and back on tracks!**** > > ** ** > > Go check another Erlang doc at http://erldocs.com/**** > > Go check the code at https://github.com/fenollp/erldocs**** > > ** ** > > ** ** > > Cheers,**** > > -- **** > > Pierre Fenoll**** > > ** ** > > ** ** > > _______________________________________________ > 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 Oct 2 16:54:32 2013 From: essen@REDACTED (=?windows-1252?Q?Lo=EFc_Hoguin?=) Date: Wed, 02 Oct 2013 16:54:32 +0200 Subject: [erlang-questions] Fwd: erldocs.com updated! In-Reply-To: References: Message-ID: <524C33A8.7060300@ninenines.eu> See commit 229d0d8ca88bc344bed89e46541b325c1d267996 On 10/02/2013 04:52 PM, Pierre Fenoll wrote: > Hey Ola, > > `diff -y otp_src_R1{4,6}B02/lib/stdlib/doc/src/gb_trees.xml | less` > shows that type information (and argument names) were removed moving > from R14B02 to R16B02. > > Maybe someone can hint to where this information was moved? as I > hope^Wbelieve it didn't just got trashed. > > erldocs only provides a different compiled documentation. The source > files are still just those found under doc/src/*.xml and maintained by > Ericsson/the community. > Sorry but you (well, we both) will have to s/R16/R14/ the URL for now? > > > Cheers, > -- > Pierre Fenoll > > > > On 2 October 2013 15:33, Ola B?ckstr?m > wrote: > > Excellent news,____ > > __ __ > > Thanks Pierre for your work to keep erldocs updated, it is one of my > top-10 links!____ > > __ __ > > A question, is there a reason for the documentation of newer > Erlang/OTP versions not to provide type information? ____ > > For instance R14B02 do provide that, in yellow boxes. Compare____ > > ____ > > http://erldocs.com/R14B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1____ > > with____ > > http://erldocs.com/R16B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1____ > > __ __ > > The first link shows that the function argument should be of type > gb_tree() but the latter not.____ > > __ __ > > /Ola____ > > __ __ > > *From:*erlang-questions-bounces@REDACTED > > [mailto:erlang-questions-bounces@REDACTED > ] *On Behalf Of *Pierre > Fenoll > *Sent:* den 2 oktober 2013 16:03 > *To:* erlang-questions@REDACTED > Questions > *Subject:* [erlang-questions] Fwd: erldocs.com > updated!____ > > __ __ > > Hi,____ > > __ __ > > http://erldocs.com is a fast and accessible alternative to the > official Erlang/OTP documentation.____ > > Originally developed by Dale Harvey, it was no longer supported > since the release of R15B.____ > > __ __ > > I recently took over erldocs.com and the > erldocs GitHub project, fixed some issues and compiled documentation > for all Erlang/OTP versions. The website is now hosted on GitHub > gh-pages as it is only static files (thank you GitHub, that's > amazing!) and back on tracks!____ > > __ __ > > Go check another Erlang doc at http://erldocs.com/____ > > Go check the code at > https://github.com/fenollp/erldocs____ > > __ __ > > __ __ > > Cheers,____ > > -- ____ > > Pierre Fenoll____ > > __ __ > > __ __ > > > _______________________________________________ > 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 Erlang Cowboy Nine Nines http://ninenines.eu From n.oxyde@REDACTED Wed Oct 2 16:57:01 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 2 Oct 2013 16:57:01 +0200 Subject: [erlang-questions] erldocs.com updated! In-Reply-To: References: Message-ID: <9416CC5E-8319-4652-8C4D-E96C9D311241@gmail.com> There is also http://www.erlang.org/erldoc Le 2 oct. 2013 ? 16:03, Pierre Fenoll a ?crit : > Hi, > > http://erldocs.com is a fast and accessible alternative to the official Erlang/OTP documentation. > Originally developed by Dale Harvey, it was no longer supported since the release of R15B. > > I recently took over erldocs.com and the erldocs GitHub project, fixed some issues and compiled documentation for all Erlang/OTP versions. The website is now hosted on GitHub gh-pages as it is only static files (thank you GitHub, that's amazing!) and back on tracks! > > Go check another Erlang doc at http://erldocs.com/ > Go check the code at https://github.com/fenollp/erldocs > > > Cheers, > -- > Pierre Fenoll > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Anthony Ramine From Ola.Backstrom@REDACTED Wed Oct 2 17:13:52 2013 From: Ola.Backstrom@REDACTED (=?utf-8?B?T2xhICBCw6Rja3N0csO2bQ==?=) Date: Wed, 2 Oct 2013 15:13:52 +0000 Subject: [erlang-questions] Fwd: erldocs.com updated! In-Reply-To: References: Message-ID: <591ce2041874446e827db38092d6ce50@exsrvfe.ls.local> Seeing Anthony R?s post I just noticed that there?s nowadays also a search field in http://www.erlang.org/erldoc. Never saw that before, anyway it contains types. /Ola From: Pierre Fenoll [mailto:pierrefenoll@REDACTED] Sent: den 2 oktober 2013 16:52 To: Ola B?ckstr?m Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Fwd: erldocs.com updated! Hey Ola, `diff -y otp_src_R1{4,6}B02/lib/stdlib/doc/src/gb_trees.xml | less` shows that type information (and argument names) were removed moving from R14B02 to R16B02. Maybe someone can hint to where this information was moved? as I hope^Wbelieve it didn't just got trashed. erldocs only provides a different compiled documentation. The source files are still just those found under doc/src/*.xml and maintained by Ericsson/the community. Sorry but you (well, we both) will have to s/R16/R14/ the URL for now? Cheers, -- Pierre Fenoll On 2 October 2013 15:33, Ola B?ckstr?m > wrote: Excellent news, Thanks Pierre for your work to keep erldocs updated, it is one of my top-10 links! A question, is there a reason for the documentation of newer Erlang/OTP versions not to provide type information? For instance R14B02 do provide that, in yellow boxes. Compare http://erldocs.com/R14B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 with http://erldocs.com/R16B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 The first link shows that the function argument should be of type gb_tree() but the latter not. /Ola From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Pierre Fenoll Sent: den 2 oktober 2013 16:03 To: erlang-questions@REDACTED Questions Subject: [erlang-questions] Fwd: erldocs.com updated! Hi, http://erldocs.com is a fast and accessible alternative to the official Erlang/OTP documentation. Originally developed by Dale Harvey, it was no longer supported since the release of R15B. I recently took over erldocs.com and the erldocs GitHub project, fixed some issues and compiled documentation for all Erlang/OTP versions. The website is now hosted on GitHub gh-pages as it is only static files (thank you GitHub, that's amazing!) and back on tracks! Go check another Erlang doc at http://erldocs.com/ Go check the code at https://github.com/fenollp/erldocs Cheers, -- Pierre Fenoll _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Wed Oct 2 17:34:23 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Wed, 2 Oct 2013 16:34:23 +0100 Subject: [erlang-questions] Fwd: erldocs.com updated! In-Reply-To: <591ce2041874446e827db38092d6ce50@exsrvfe.ls.local> References: <591ce2041874446e827db38092d6ce50@exsrvfe.ls.local> Message-ID: Hey, now that type specs are fetched from doc/specs/ as I infer from [1], how come that folder is always empty? How does one generate those xml specs? [1] https://github.com/erlang/otp/commit/229d0d8ca88bc344bed89e46541b325c1d267996(thanks Loic) Cheers, -- Pierre Fenoll On 2 October 2013 16:13, Ola B?ckstr?m wrote: > Seeing Anthony R?s post I just noticed that there?s nowadays also a > search field in http://www.erlang.org/erldoc. > Never saw that before, anyway it contains types.**** > > /Ola**** > > ** ** > > *From:* Pierre Fenoll [mailto:pierrefenoll@REDACTED] > *Sent:* den 2 oktober 2013 16:52 > *To:* Ola B?ckstr?m > *Cc:* erlang-questions@REDACTED > *Subject:* Re: [erlang-questions] Fwd: erldocs.com updated!**** > > ** ** > > Hey Ola,**** > > ** ** > > `diff -y otp_src_R1{4,6}B02/lib/stdlib/doc/src/gb_trees.xml | less` shows > that type information (and argument names) were removed moving from R14B02 > to R16B02.**** > > ** ** > > Maybe someone can hint to where this information was moved? as I > hope^Wbelieve it didn't just got trashed.**** > > ** ** > > erldocs only provides a different compiled documentation. The source files > are still just those found under doc/src/*.xml and maintained by > Ericsson/the community.**** > > Sorry but you (well, we both) will have to s/R16/R14/ the URL for now?**** > > > **** > > ** ** > > Cheers,**** > > -- **** > > Pierre Fenoll**** > > ** ** > > ** ** > > On 2 October 2013 15:33, Ola B?ckstr?m wrote:* > *** > > Excellent news,**** > > **** > > Thanks Pierre for your work to keep erldocs updated, it is one of my > top-10 links!**** > > **** > > A question, is there a reason for the documentation of newer Erlang/OTP > versions not to provide type information? **** > > For instance R14B02 do provide that, in yellow boxes. Compare**** > > > http://erldocs.com/R14B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 > **** > > with**** > > > http://erldocs.com/R16B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 > **** > > **** > > The first link shows that the function argument should be of type > gb_tree() but the latter not.**** > > **** > > /Ola**** > > **** > > *From:* erlang-questions-bounces@REDACTED [mailto: > erlang-questions-bounces@REDACTED] *On Behalf Of *Pierre Fenoll > *Sent:* den 2 oktober 2013 16:03 > *To:* erlang-questions@REDACTED Questions > *Subject:* [erlang-questions] Fwd: erldocs.com updated!**** > > **** > > Hi,**** > > **** > > http://erldocs.com is a fast and accessible alternative to the official > Erlang/OTP documentation.**** > > Originally developed by Dale Harvey, it was no longer supported since the > release of R15B.**** > > **** > > I recently took over erldocs.com and the erldocs GitHub project, fixed > some issues and compiled documentation for all Erlang/OTP versions. The > website is now hosted on GitHub gh-pages as it is only static files (thank > you GitHub, that's amazing!) and back on tracks!**** > > **** > > Go check another Erlang doc at http://erldocs.com/**** > > Go check the code at https://github.com/fenollp/erldocs**** > > **** > > **** > > Cheers,**** > > -- **** > > Pierre Fenoll**** > > **** > > **** > > > _______________________________________________ > 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 wallentin.dahlberg@REDACTED Wed Oct 2 22:36:40 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Wed, 2 Oct 2013 22:36:40 +0200 Subject: [erlang-questions] Fwd: erldocs.com updated! In-Reply-To: References: <591ce2041874446e827db38092d6ce50@exsrvfe.ls.local> Message-ID: I believe this is used: lib/erl_docgen/priv/bin/specs_gen.escript see script for details. // Bj?rn-Egil 2013/10/2 Pierre Fenoll > Hey, now that type specs are fetched from doc/specs/ as I infer from [1], > how come that folder is always empty? > How does one generate those xml specs? > > [1] > https://github.com/erlang/otp/commit/229d0d8ca88bc344bed89e46541b325c1d267996(thanks Loic) > > > Cheers, > -- > Pierre Fenoll > > > > On 2 October 2013 16:13, Ola B?ckstr?m wrote: > >> Seeing Anthony R?s post I just noticed that there?s nowadays also a >> search field in http://www.erlang.org/erldoc. >> Never saw that before, anyway it contains types.**** >> >> /Ola**** >> >> ** ** >> >> *From:* Pierre Fenoll [mailto:pierrefenoll@REDACTED] >> *Sent:* den 2 oktober 2013 16:52 >> *To:* Ola B?ckstr?m >> *Cc:* erlang-questions@REDACTED >> *Subject:* Re: [erlang-questions] Fwd: erldocs.com updated!**** >> >> ** ** >> >> Hey Ola,**** >> >> ** ** >> >> `diff -y otp_src_R1{4,6}B02/lib/stdlib/doc/src/gb_trees.xml | less` shows >> that type information (and argument names) were removed moving from R14B02 >> to R16B02.**** >> >> ** ** >> >> Maybe someone can hint to where this information was moved? as I >> hope^Wbelieve it didn't just got trashed.**** >> >> ** ** >> >> erldocs only provides a different compiled documentation. The source >> files are still just those found under doc/src/*.xml and maintained by >> Ericsson/the community.**** >> >> Sorry but you (well, we both) will have to s/R16/R14/ the URL for now?*** >> * >> >> >> **** >> >> ** ** >> >> Cheers,**** >> >> -- **** >> >> Pierre Fenoll**** >> >> ** ** >> >> ** ** >> >> On 2 October 2013 15:33, Ola B?ckstr?m wrote: >> **** >> >> Excellent news,**** >> >> **** >> >> Thanks Pierre for your work to keep erldocs updated, it is one of my >> top-10 links!**** >> >> **** >> >> A question, is there a reason for the documentation of newer Erlang/OTP >> versions not to provide type information? **** >> >> For instance R14B02 do provide that, in yellow boxes. Compare**** >> >> >> http://erldocs.com/R14B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 >> **** >> >> with**** >> >> >> http://erldocs.com/R16B02/stdlib/gb_trees.html?i=0&search=gb_trees:balance#balance/1 >> **** >> >> **** >> >> The first link shows that the function argument should be of type >> gb_tree() but the latter not.**** >> >> **** >> >> /Ola**** >> >> **** >> >> *From:* erlang-questions-bounces@REDACTED [mailto: >> erlang-questions-bounces@REDACTED] *On Behalf Of *Pierre Fenoll >> *Sent:* den 2 oktober 2013 16:03 >> *To:* erlang-questions@REDACTED Questions >> *Subject:* [erlang-questions] Fwd: erldocs.com updated!**** >> >> **** >> >> Hi,**** >> >> **** >> >> http://erldocs.com is a fast and accessible alternative to the official >> Erlang/OTP documentation.**** >> >> Originally developed by Dale Harvey, it was no longer supported since the >> release of R15B.**** >> >> **** >> >> I recently took over erldocs.com and the erldocs GitHub project, fixed >> some issues and compiled documentation for all Erlang/OTP versions. The >> website is now hosted on GitHub gh-pages as it is only static files (thank >> you GitHub, that's amazing!) and back on tracks!**** >> >> **** >> >> Go check another Erlang doc at http://erldocs.com/**** >> >> Go check the code at https://github.com/fenollp/erldocs*** >> * >> >> **** >> >> **** >> >> Cheers,**** >> >> -- **** >> >> Pierre Fenoll**** >> >> **** >> >> **** >> >> >> _______________________________________________ >> 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 jon@REDACTED Thu Oct 3 10:09:46 2013 From: jon@REDACTED (Jon Schneider) Date: Thu, 3 Oct 2013 09:09:46 +0100 Subject: [erlang-questions] config files In-Reply-To: <524BE67E.4000204@ninenines.eu> References: <2e532de8d21d99ca7cd1f72357d27b81.squirrel@mail.jschneider.net> <524BE67E.4000204@ninenines.eu> Message-ID: Silly me. Thanks. Doesn't quite explain the error message saying there's no application kernel though. Is whoever is in charge of website documentation listening in ? Jon > Incidentally at http://www.erlang.org/doc/man/config.html under sys.config > a closing square bracket is missing in the first code snippet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Fri Oct 4 00:58:11 2013 From: comptekki@REDACTED (Wes James) Date: Thu, 3 Oct 2013 16:58:11 -0600 Subject: [erlang-questions] self signed certs problem Message-ID: Somewhere along the line I've started having issues with self-signed certs. On xubuntu I've: recently upgraded chrome and firefox (both having issues) recently upgraded cowboy to master recently upgrade to 16B02 (compiled then installed) I'm having issues accessing sites on https now. I get an error from firefox, but try to accept but get a security error. On chrome, it just says it can't get to the site. I then tried opera. I have to confirm some boxes on opera, but I can finally see the https sites. Anyone else having these issues? I've tried going back to 16B, but still have the issues so I'm not sure if it is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, but still have the same issues (where it was working fine before), so I'm not sure where the problem is. Thanks, Wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From siraaj@REDACTED Fri Oct 4 04:48:29 2013 From: siraaj@REDACTED (Siraaj Khandkar) Date: Thu, 03 Oct 2013 22:48:29 -0400 Subject: [erlang-questions] Module language for Dialyzer? Message-ID: <524E2C7D.2010901@khandkar.net> What are the theoretical problems (if any) with an idea of extending Dialyzer with a module language to express composable interfaces in the spirit of SML? Something along the line of: dict.esig: -signature(dict) :: sig -type t(K, V) :: opaque(). -fun new() -> t(K, V). -fun add(t(K, V), K, V) -> t(K, V). -fun find(t(K, V), K) -> none | {some, V}. ... end. stringable.esig: -signature(stringable) :: sig -type t() :: opaque(). -fun to_string(t()) -> string(). -fun of_string(string()) -> t(). ... end. my_serializable_dict.erl: -module(my_serializable_dict). -implements([dict, stringable]). ... Syntax is not the point of this, so don't get hung-up on it for the purpose of this question - I'm making it up as I type :) From pierrefenoll@REDACTED Fri Oct 4 07:21:17 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Fri, 4 Oct 2013 06:21:17 +0100 Subject: [erlang-questions] Module language for Dialyzer? In-Reply-To: <524E2C7D.2010901@khandkar.net> References: <524E2C7D.2010901@khandkar.net> Message-ID: <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> A module spec can be useful to throw compile-time warnings when implementing generic handlers. (A generic handler being a collection of functions calling specific functions from another module.) Though, a "module signature" already exists (-callback used in pair with -behavior), currently there is no way to check if the other module implements the required functions. I think it would be a great addition. > On 4 oct. 2013, at 03:48, Siraaj Khandkar wrote: > > What are the theoretical problems (if any) with an idea of extending Dialyzer with a module language to express composable interfaces in the spirit of SML? > > Something along the line of: > > dict.esig: > -signature(dict) :: > sig > -type t(K, V) :: opaque(). > -fun new() -> t(K, V). > -fun add(t(K, V), K, V) -> t(K, V). > -fun find(t(K, V), K) -> none | {some, V}. > ... > end. > > stringable.esig: > -signature(stringable) :: > sig > -type t() :: opaque(). > -fun to_string(t()) -> string(). > -fun of_string(string()) -> t(). > ... > end. > > my_serializable_dict.erl: > -module(my_serializable_dict). > -implements([dict, stringable]). > ... > > > Syntax is not the point of this, so don't get hung-up on it for the purpose of this question - I'm making it up as I type :) > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ingela.andin@REDACTED Fri Oct 4 09:44:33 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 4 Oct 2013 09:44:33 +0200 Subject: [erlang-questions] self signed certs problem In-Reply-To: References: Message-ID: Hi Wes! I have heard from several sources that they have problems connecting with Firefox and Chrome when Elliptic curve cipher suites are enabled. Elliptic curve ciphers where first supported at all in R16 and are by default enabled, although will not be used if the client does not claim to be able to use them. It does seem though that other clients can connect like curl, s_client (openssl), some python client and now opera. I also know that some ECC ciphers are broken in openssl version 1.0.0 and 1.0.0.a. So it seems like it is a client problem that you may workaround by disabling Elliptic Curve cipher suites until the clients get fixed. Also R16B02 fixes an ECC bug so R16B will not be better then R16B02, going back to R15 will work as the ECC ciphers where not supported at all, but I can see other reasons you would not want to do that. Regards Ingela Erlang/OTP team - Ericsson AB 2013/10/4 Wes James > Somewhere along the line I've started having issues with self-signed certs. > > On xubuntu I've: > > recently upgraded chrome and firefox (both having issues) > > recently upgraded cowboy to master > > recently upgrade to 16B02 (compiled then installed) > > I'm having issues accessing sites on https now. I get an error from > firefox, but try to accept but get a security error. On chrome, it just > says it can't get to the site. I then tried opera. I have to confirm some > boxes on opera, but I can finally see the https sites. > > Anyone else having these issues? > > I've tried going back to 16B, but still have the issues so I'm not sure if > it is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, but > still have the same issues (where it was working fine before), so I'm not > sure where the problem is. > > Thanks, > > Wes > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Fri Oct 4 10:02:07 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Fri, 4 Oct 2013 10:02:07 +0200 (CEST) Subject: [erlang-questions] self signed certs problem In-Reply-To: References: Message-ID: <813054964.97046.1380873727742.JavaMail.zimbra@tpip.net> Hi Wes, Chrome tries to validate the issuer and the CRL's for all certificates. When that fails, it will display an error page that looks much like a connection problem. Does the certificate contain a CRL or OSCP reference? And could you share a sample certificate that has this problem? Regards Andreas ----- Original Message ----- > Somewhere along the line I've started having issues with self-signed certs. > > On xubuntu I've: > > recently upgraded chrome and firefox (both having issues) > > recently upgraded cowboy to master > > recently upgrade to 16B02 (compiled then installed) > > I'm having issues accessing sites on https now. I get an error from firefox, > but try to accept but get a security error. On chrome, it just says it can't > get to the site. I then tried opera. I have to confirm some boxes on opera, > but I can finally see the https sites. > > Anyone else having these issues? > > I've tried going back to 16B, but still have the issues so I'm not sure if it > is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, but > still have the same issues (where it was working fine before), so I'm not > sure where the problem is. > > Thanks, > > Wes > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From cmeiklejohn@REDACTED Fri Oct 4 16:35:50 2013 From: cmeiklejohn@REDACTED (Christopher Meiklejohn) Date: Fri, 4 Oct 2013 09:35:50 -0500 Subject: [erlang-questions] self signed certs problem In-Reply-To: References: Message-ID: <30CB8B71923F48D19B4EE548673221C6@basho.com> Hi Ingela, We've also been experiencing what seems to be the same problem using self-signed certificates. I've verified that the same certificates, while producing a CA certificate error in R15B03 works, but fails to connect in R16B02 with no error in any logs. - Chris -- Christopher Meiklejohn Software Engineer Basho Technologies, Inc. On Friday, October 4, 2013 at 2:44 AM, Ingela Andin wrote: > Hi Wes! > > I have heard from several sources that they have problems connecting with Firefox and Chrome > when Elliptic curve cipher suites are enabled. Elliptic curve ciphers where first supported at all in R16 and are by default enabled, although will not be used if the client does not claim to be able to use them. > It does seem though that other clients can connect like curl, s_client (openssl), some python client and now opera. I also know that some ECC ciphers are broken in openssl version 1.0.0 and 1.0.0.a. > So it seems like it is a client problem that you may workaround by disabling Elliptic Curve cipher suites > until the clients get fixed. Also R16B02 fixes an ECC bug so R16B will not be better then R16B02, going > back to R15 will work as the ECC ciphers where not supported at all, but I can see other reasons you would not want to do that. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > 2013/10/4 Wes James > > Somewhere along the line I've started having issues with self-signed certs. > > > > On xubuntu I've: > > > > recently upgraded chrome and firefox (both having issues) > > > > recently upgraded cowboy to master > > > > recently upgrade to 16B02 (compiled then installed) > > > > I'm having issues accessing sites on https now. I get an error from firefox, but try to accept but get a security error. On chrome, it just says it can't get to the site. I then tried opera. I have to confirm some boxes on opera, but I can finally see the https sites. > > > > Anyone else having these issues? > > > > I've tried going back to 16B, but still have the issues so I'm not sure if it is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, but still have the same issues (where it was working fine before), so I'm not sure where the problem is. > > > > Thanks, > > > > Wes > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions From comptekki@REDACTED Fri Oct 4 16:48:09 2013 From: comptekki@REDACTED (Wes James) Date: Fri, 4 Oct 2013 08:48:09 -0600 Subject: [erlang-questions] self signed certs problem In-Reply-To: References: Message-ID: How would I do this in the .app.src? I have: {application, dbswui, [ {description, "database search web ui."}, {vsn, "0.1.0"}, {modules, []}, {registered, []}, {applications, [ kernel, stdlib, crypto, public_key, cowlib, cowboy, ssl ]}, {mod, {dbswui_app, []}}, {env, []} ]}. I have this from a previous email from you on list. {ciphers, [{dhe_rsa,aes_256_cbc,sha256}, {dhe_dss,aes_256_cbc,sha256}, {rsa,aes_256_cbc,sha256}, {dhe_rsa,aes_128_cbc,sha256}, {dhe_dss,aes_128_cbc,sha256}, {rsa,aes_128_cbc,sha256}, {dhe_rsa,aes_256_cbc,sha}, {dhe_dss,aes_256_cbc,sha}, {rsa,aes_256_cbc,sha}, {dhe_rsa,'3des_ede_cbc',sha}, {dhe_dss,'3des_ede_cbc',sha}, {rsa,'3des_ede_cbc',sha}, {dhe_rsa,aes_128_cbc,sha}, {dhe_dss,aes_128_cbc,sha}, {rsa,aes_128_cbc,sha}, {rsa,rc4_128,sha}, {rsa,rc4_128,md5}, {dhe_rsa,des_cbc,sha}, {rsa,des_cbc,sha}]} I tried to put this in the env [] list, but it didn't help. Thanks, Wes On Fri, Oct 4, 2013 at 1:44 AM, Ingela Andin wrote: > Hi Wes! > > I have heard from several sources that they have problems connecting with > Firefox and Chrome > when Elliptic curve cipher suites are enabled. Elliptic curve ciphers > where first supported at all in R16 and are by default enabled, although > will not be used if the client does not claim to be able to use them. > It does seem though that other clients can connect like curl, s_client > (openssl), some python client and now opera. I also know that some ECC > ciphers are broken in openssl version 1.0.0 and 1.0.0.a. > So it seems like it is a client problem that you may workaround by > disabling Elliptic Curve cipher suites > until the clients get fixed. Also R16B02 fixes an ECC bug so R16B will not > be better then R16B02, going > back to R15 will work as the ECC ciphers where not supported at all, but I > can see other reasons you would not want to do that. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > 2013/10/4 Wes James > >> Somewhere along the line I've started having issues with self-signed >> certs. >> >> On xubuntu I've: >> >> recently upgraded chrome and firefox (both having issues) >> >> recently upgraded cowboy to master >> >> recently upgrade to 16B02 (compiled then installed) >> >> I'm having issues accessing sites on https now. I get an error from >> firefox, but try to accept but get a security error. On chrome, it just >> says it can't get to the site. I then tried opera. I have to confirm some >> boxes on opera, but I can finally see the https sites. >> >> Anyone else having these issues? >> >> I've tried going back to 16B, but still have the issues so I'm not sure >> if it is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, >> but still have the same issues (where it was working fine before), so I'm >> not sure where the problem is. >> >> Thanks, >> >> Wes >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Fri Oct 4 19:11:31 2013 From: comptekki@REDACTED (Wes James) Date: Fri, 4 Oct 2013 11:11:31 -0600 Subject: [erlang-questions] self signed certs problem In-Reply-To: References: Message-ID: I found where to fix this for now in Lo?c's ranch_ssl.erl: %% Unfortunately the implementation of elliptic-curve ciphers that has %% been introduced in R16B01 is incomplete. Depending on the particular %% client, this can cause the TLS handshake to break during key %% agreement. Depending on the ssl application version, this function %% returns a list of all cipher suites that are supported by default, %% minus the elliptic-curve ones. -spec unbroken_cipher_suites() -> [ssl:erl_cipher_suite()]. unbroken_cipher_suites() -> case proplists:get_value(ssl_app, ssl:versions()) of "5.3" -> lists:filter(fun(Suite) -> string:left(atom_to_list(element(1, Suite)), 4) =/= "ecdh" end, ssl:cipher_suites()); _ -> %io:format("~n cipher suites: ~p ~n",[ssl:cipher_suites()]), %ssl:cipher_suites(), [{dhe_rsa,aes_256_cbc,sha256}, {dhe_dss,aes_256_cbc,sha256}, {rsa,aes_256_cbc,sha256}, {dhe_rsa,aes_128_cbc,sha256}, {dhe_dss,aes_128_cbc,sha256}, {rsa,aes_128_cbc,sha256}, {dhe_rsa,aes_256_cbc,sha}, {dhe_dss,aes_256_cbc,sha}, {rsa,aes_256_cbc,sha}, {dhe_rsa,'3des_ede_cbc',sha}, {dhe_dss,'3des_ede_cbc',sha}, {rsa,'3des_ede_cbc',sha}, {dhe_rsa,aes_128_cbc,sha}, {dhe_dss,aes_128_cbc,sha}, {rsa,aes_128_cbc,sha}, {rsa,rc4_128,sha}, {rsa,rc4_128,md5}, {dhe_rsa,des_cbc,sha}, {rsa,des_cbc,sha}] end. Thanks, -wes On Fri, Oct 4, 2013 at 8:48 AM, Wes James wrote: > How would I do this in the .app.src? > > I have: > > {application, dbswui, [ > {description, "database search web ui."}, > {vsn, "0.1.0"}, > {modules, []}, > {registered, []}, > {applications, [ > kernel, > stdlib, > crypto, > public_key, > cowlib, > cowboy, > ssl > ]}, > {mod, {dbswui_app, []}}, > {env, []} > ]}. > > I have this from a previous email from you on list. > > {ciphers, [{dhe_rsa,aes_256_cbc,sha256}, > {dhe_dss,aes_256_cbc,sha256}, > {rsa,aes_256_cbc,sha256}, > {dhe_rsa,aes_128_cbc,sha256}, > {dhe_dss,aes_128_cbc,sha256}, > {rsa,aes_128_cbc,sha256}, > {dhe_rsa,aes_256_cbc,sha}, > {dhe_dss,aes_256_cbc,sha}, > {rsa,aes_256_cbc,sha}, > {dhe_rsa,'3des_ede_cbc',sha}, > {dhe_dss,'3des_ede_cbc',sha}, > {rsa,'3des_ede_cbc',sha}, > {dhe_rsa,aes_128_cbc,sha}, > {dhe_dss,aes_128_cbc,sha}, > {rsa,aes_128_cbc,sha}, > {rsa,rc4_128,sha}, > {rsa,rc4_128,md5}, > {dhe_rsa,des_cbc,sha}, > {rsa,des_cbc,sha}]} > > I tried to put this in the env [] list, but it didn't help. > > Thanks, > > Wes > > > > > On Fri, Oct 4, 2013 at 1:44 AM, Ingela Andin wrote: > >> Hi Wes! >> >> I have heard from several sources that they have problems connecting >> with Firefox and Chrome >> when Elliptic curve cipher suites are enabled. Elliptic curve ciphers >> where first supported at all in R16 and are by default enabled, although >> will not be used if the client does not claim to be able to use them. >> It does seem though that other clients can connect like curl, s_client >> (openssl), some python client and now opera. I also know that some ECC >> ciphers are broken in openssl version 1.0.0 and 1.0.0.a. >> So it seems like it is a client problem that you may workaround by >> disabling Elliptic Curve cipher suites >> until the clients get fixed. Also R16B02 fixes an ECC bug so R16B will >> not be better then R16B02, going >> back to R15 will work as the ECC ciphers where not supported at all, but >> I can see other reasons you would not want to do that. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> >> >> 2013/10/4 Wes James >> >>> Somewhere along the line I've started having issues with self-signed >>> certs. >>> >>> On xubuntu I've: >>> >>> recently upgraded chrome and firefox (both having issues) >>> >>> recently upgraded cowboy to master >>> >>> recently upgrade to 16B02 (compiled then installed) >>> >>> I'm having issues accessing sites on https now. I get an error from >>> firefox, but try to accept but get a security error. On chrome, it just >>> says it can't get to the site. I then tried opera. I have to confirm some >>> boxes on opera, but I can finally see the https sites. >>> >>> Anyone else having these issues? >>> >>> I've tried going back to 16B, but still have the issues so I'm not sure >>> if it is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, >>> but still have the same issues (where it was working fine before), so I'm >>> not sure where the problem is. >>> >>> Thanks, >>> >>> Wes >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Fri Oct 4 20:47:15 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 4 Oct 2013 20:47:15 +0200 Subject: [erlang-questions] self signed certs problem In-Reply-To: <30CB8B71923F48D19B4EE548673221C6@basho.com> References: <30CB8B71923F48D19B4EE548673221C6@basho.com> Message-ID: Hi Christopher! Would it be possible for you to create an example self-signed cert that fails and that you could send to me? Regards Ingela Erlang/OTP team - Ericsson AB 2013/10/4 Christopher Meiklejohn > Hi Ingela, > > We've also been experiencing what seems to be the same problem using > self-signed certificates. I've verified that the same certificates, while > producing a CA certificate error in R15B03 works, but fails to connect in > R16B02 with no error in any logs. > > - Chris > > -- > Christopher Meiklejohn > Software Engineer > Basho Technologies, Inc. > > > > On Friday, October 4, 2013 at 2:44 AM, Ingela Andin wrote: > > > Hi Wes! > > > > I have heard from several sources that they have problems connecting > with Firefox and Chrome > > when Elliptic curve cipher suites are enabled. Elliptic curve ciphers > where first supported at all in R16 and are by default enabled, although > will not be used if the client does not claim to be able to use them. > > It does seem though that other clients can connect like curl, s_client > (openssl), some python client and now opera. I also know that some ECC > ciphers are broken in openssl version 1.0.0 and 1.0.0.a. > > So it seems like it is a client problem that you may workaround by > disabling Elliptic Curve cipher suites > > until the clients get fixed. Also R16B02 fixes an ECC bug so R16B will > not be better then R16B02, going > > back to R15 will work as the ECC ciphers where not supported at all, but > I can see other reasons you would not want to do that. > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > > > > > 2013/10/4 Wes James > > > Somewhere along the line I've started having issues with self-signed > certs. > > > > > > On xubuntu I've: > > > > > > recently upgraded chrome and firefox (both having issues) > > > > > > recently upgraded cowboy to master > > > > > > recently upgrade to 16B02 (compiled then installed) > > > > > > I'm having issues accessing sites on https now. I get an error from > firefox, but try to accept but get a security error. On chrome, it just > says it can't get to the site. I then tried opera. I have to confirm some > boxes on opera, but I can finally see the https sites. > > > > > > Anyone else having these issues? > > > > > > I've tried going back to 16B, but still have the issues so I'm not > sure if it is erlang. I've tried compiling code with 0.8.1 of cowboy with > 16B, but still have the same issues (where it was working fine before), so > I'm not sure where the problem is. > > > > > > Thanks, > > > > > > Wes > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > 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 comptekki@REDACTED Fri Oct 4 21:07:10 2013 From: comptekki@REDACTED (Wes James) Date: Fri, 4 Oct 2013 13:07:10 -0600 Subject: [erlang-questions] self signed certs problem In-Reply-To: <813054964.97046.1380873727742.JavaMail.zimbra@tpip.net> References: <813054964.97046.1380873727742.JavaMail.zimbra@tpip.net> Message-ID: I use this script to create the self-signed certs: #!/bin/bash if [ -a ./priv/ssl/cert.pem -o -a ./priv/ssl/key.pem ] then echo echo "priv/ssl/cert.pem and/or priv/ssl/key.pem already exist." echo "Delete priv/ssl/cert.pem or priv/ssl/key.pem to create new ones." echo else mkdir -p priv/ssl umask 077 && touch priv/ssl/key.pem priv/ssl/cert.pem openssl genrsa 2048 > priv/ssl/key.pem openssl req -new -x509 -nodes -sha1 -days 3650 -out priv/ssl/cert.pem -key priv/ssl/key.pem < blank echo echo echo "Done creating cert..." echo fi the file "blank" has this text: US some-state some-city some-org some-unit some-host some-address -wes On Fri, Oct 4, 2013 at 2:02 AM, Andreas Schultz wrote: > Hi Wes, > > Chrome tries to validate the issuer and the CRL's for all certificates. > When > that fails, it will display an error page that looks much like a connection > problem. > > Does the certificate contain a CRL or OSCP reference? And could you share a > sample certificate that has this problem? > > Regards > Andreas > > ----- Original Message ----- > > Somewhere along the line I've started having issues with self-signed > certs. > > > > On xubuntu I've: > > > > recently upgraded chrome and firefox (both having issues) > > > > recently upgraded cowboy to master > > > > recently upgrade to 16B02 (compiled then installed) > > > > I'm having issues accessing sites on https now. I get an error from > firefox, > > but try to accept but get a security error. On chrome, it just says it > can't > > get to the site. I then tried opera. I have to confirm some boxes on > opera, > > but I can finally see the https sites. > > > > Anyone else having these issues? > > > > I've tried going back to 16B, but still have the issues so I'm not sure > if it > > is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, but > > still have the same issues (where it was working fine before), so I'm not > > sure where the problem is. > > > > Thanks, > > > > Wes > > > > _______________________________________________ > > 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 Fri Oct 4 22:26:13 2013 From: ryankbrown@REDACTED (Ryan Brown) Date: Fri, 4 Oct 2013 14:26:13 -0600 Subject: [erlang-questions] Creating an ssl over TCP ping server Message-ID: Ok, this seems like it should be a very simple thing to do but I appear to be having trouble finding documentation on how to do it without incorporating external resources. I just want a simple module where I can generate load via https without using a webserver library like ibrowse to recieve the messages. Essentially, I just need something like this: start(port) -> start_webserver_listening_on_port(port), receive_loop(). receive_loop() -> whatever. client(Msg_To_Send) -> send_msg_to_server_started_above(Msg_To_Send). These can/maybe should be, different modules. That's fine. I just want to do this in pure erlang and cannot seem to get it worked-out from what I can find online. (Feeling dumb) Thanks in advance! Ryan -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryankbrown@REDACTED Fri Oct 4 22:31:51 2013 From: ryankbrown@REDACTED (Ryan Brown) Date: Fri, 4 Oct 2013 14:31:51 -0600 Subject: [erlang-questions] Problematic SSL message publication In-Reply-To: References: Message-ID: In resolution, it appears that the only way we have been able to resolve our issue was to stop reusing ssl sessions. With Ingeal's great help we were able to track-down several symptoms. (Many connections being started resulting in the ssl_otp_session_cache ets table growing quite large and the ets lookup to find the best session to reuse taking ~45msec each time.) By removing session reuse we are forcing re-negotiation on each connection but this has proven to still be faster than incurring the ets table lookup. Thank you very much Ingela. Hoepfully we can figure-out a better long-term solution in the near future. Best, Ryan Brown On Thu, Sep 26, 2013 at 1:51 AM, Ingela Andin wrote: > Hi Ryan! > > > On Wed, Sep 25, 2013 at 11:28 PM, Ryan Brown wrote: > >> Thank you Ingela. I will work on creating a test to compare to openssl. >> >> > When you do the test with openssl make sure that you run the same cipher > suit as when you run erlang, and > the same version of the TLS protocol. > > > >> In the mean time, what we are currently doing is this. Our application >> sends requests to various hosts via ibrowse (http/s). The messages are >> basic HTTP form POSTs (application/x-www-form-urlencoded). Our test just >> sends these messages to our application which pops them on a queue in >> RabbitMQ then one-by-one pulls them off and attempt to deliver them. Fairly >> straightforward really. >> >> >> > But so many options and things that can be going on in under the covers > ... I will help you to look into it. > > > Regards Ingela Erlang/OTP - team Ericsson AB > > > > >> >> On Wed, Sep 25, 2013 at 2:59 PM, Ingela Andin wrote: >> >>> Hi! >>> >>> On Wed, Sep 25, 2013 at 7:07 PM, Ryan Brown wrote: >>> >>>> Excellent Ingela! By upgrading to the R!6B02 we have been able to >>>> eliminate the above stated issue with the Erlang message queues growing. >>>> However, we are still seeing VERY slow throughput to ssl endpoints. In our >>>> limited, scaled-back, test. We are seeing message throughput to an ssl >>>> endpoint at 12 msgs/sec and non-ssl of 300+ msgs/sec. Is there a connection >>>> limit for ssl connections related to Erlang directly? >>>> >>>> Thank you! >>>> >>>> >>>> >>> Could you send me more details how you are performing this test. It >>> would be interesting if I could run the same kind of test as you do. And >>> when you say messages what more exactly do mean? Messages can be on many >>> abstraction levels (tcp messages, tls messages, http messages etc). Could >>> you perform >>> the same kind of throughput test running for instance openssl? >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> >>> >>>> >>>> On Wed, Sep 25, 2013 at 6:58 AM, Ingela Andin wrote: >>>> >>>>> Hi! >>>>> >>>>> >>>>> 2013/9/25 Ryan Brown >>>>> >>>>>> Hi Ingela, >>>>>> >>>>>> Thank you for the response. I suppose I don't really know how to see >>>>>> what messages are in the ssl queue. What I am looking at is nregs and >>>>>> watching the "msgs" column growing at a steady pace. Is there a way to look >>>>>> at these messages? >>>>>> >>>>>> >>>>> You can use the observer application to look at erlang processes. >>>>> >>>>> http://www.erlang.org/erldoc?q=observe&x=0&y=0 >>>>> >>>>> >>>>> >>>>>> As for reproducing in the latest version of ssl. I was planning on >>>>>> upgrading a machine to 16 today and attempting to reproduce. This should >>>>>> get me the latest ssl version correct? >>>>>> >>>>>> >>>>> R16B02 (ssl-5.3.1) is the latest. There is a bug in ssl-5.1 (R15B02) >>>>> version (fix in ssl5.2) that perhaps could be related to your problem. >>>>> >>>>> Regards Ingela Erlang/OTP Team - Ericsson AB >>>>> >>>>> >>>>> On Wed, Sep 25, 2013 at 2:09 AM, Ingela Andin wrote: >>>>> >>>>>> >>>>>> Hi! >>>>>> >>>>>> 2013/9/24 Ryan Brown >>>>>> >>>>>>> We have a fairly high-volume (28m+ messages/day) application that >>>>>>> works, essentially, as a pub-sub for many internal and external >>>>>>> applications. We are experiencing an issue under load where and subscribers >>>>>>> that are using ssl are experiencing a significant slowness in delivery. >>>>>>> When we restart the server we begin watching the processes in our >>>>>>> application and we can, very reliably and fairly quickly, see the >>>>>>> ssl_manager_sup process message queue start increasing in size. As this >>>>>>> happens, all messages for those subscribers with ssl endpoints begin to >>>>>>> back-up and delivery slows to a near halt. >>>>>>> >>>>>>> >>>>>> What messages are there in the queue? >>>>>> >>>>>> >>>>>> It appears that ssl is a bit of a known issue within erlang. Or, at >>>>>>> least, a tricky use-case to perfect. Are there any known issues that we can >>>>>>> address in terms of configuration, best practices in setting-up ssl >>>>>>> connections or anything else for that matter we can be doing to resolve >>>>>>> this issue or more clearly identify the root cause? We're in active >>>>>>> troubleshooting mode and doing what we can to dig deeper including >>>>>>> dissecting the code to the kernel. >>>>>>> >>>>>>> We are running Erlang 15B02 (64bit). >>>>>>> >>>>>>> >>>>>>> >>>>>> So that would be ssl-5.1? Is it possible to reproduce the problem on >>>>>> the latest version ? >>>>>> >>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>>> -rb >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> -rb >>>> >>> >>> >> >> >> -- >> -rb >> > > -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Fri Oct 4 22:35:35 2013 From: comptekki@REDACTED (Wes James) Date: Fri, 4 Oct 2013 14:35:35 -0600 Subject: [erlang-questions] Creating an ssl over TCP ping server In-Reply-To: References: Message-ID: You can take a look at this to see if it helps: https://github.com/comptekki/esysman/blob/master/src/ecom.erl I can install this on windows/linux/mac workstations and then send commands to it from the esysman console. -wes On Fri, Oct 4, 2013 at 2:26 PM, Ryan Brown wrote: > Ok, this seems like it should be a very simple thing to do but I appear to > be having trouble finding documentation on how to do it without > incorporating external resources. I just want a simple module where I can > generate load via https without using a webserver library like ibrowse to > recieve the messages. > > Essentially, I just need something like this: > > start(port) -> > start_webserver_listening_on_port(port), > receive_loop(). > > receive_loop() -> > whatever. > > client(Msg_To_Send) -> > send_msg_to_server_started_above(Msg_To_Send). > > These can/maybe should be, different modules. That's fine. I just want to > do this in pure erlang and cannot seem to get it worked-out from what I can > find online. (Feeling dumb) > > Thanks in advance! > > Ryan > > -- > -rb > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Fri Oct 4 22:39:37 2013 From: comptekki@REDACTED (Wes James) Date: Fri, 4 Oct 2013 14:39:37 -0600 Subject: [erlang-questions] self signed certs problem In-Reply-To: References: Message-ID: I also found a chromium 28.x for xubuntu and installed that. It does not have the same issues as the current Chrome. Chrome/firefox must be getting closer/stricter (??) to the ssl specs? -wes On Fri, Oct 4, 2013 at 11:11 AM, Wes James wrote: > I found where to fix this for now in Lo?c's ranch_ssl.erl: > > %% Unfortunately the implementation of elliptic-curve ciphers that > has > %% been introduced in R16B01 is incomplete. Depending on the > particular > %% client, this can cause the TLS handshake to break during > key > %% agreement. Depending on the ssl application version, this > function > %% returns a list of all cipher suites that are supported by > default, > %% minus the elliptic-curve > ones. > > -spec unbroken_cipher_suites() -> [ssl:erl_cipher_suite()]. > unbroken_cipher_suites() -> > case proplists:get_value(ssl_app, ssl:versions()) of > "5.3" -> > lists:filter(fun(Suite) -> > string:left(atom_to_list(element(1, Suite)), 4) =/= "ecdh" > end, ssl:cipher_suites()); > _ -> > %io:format("~n cipher suites: ~p ~n",[ssl:cipher_suites()]), > %ssl:cipher_suites(), > > [{dhe_rsa,aes_256_cbc,sha256}, > {dhe_dss,aes_256_cbc,sha256}, > {rsa,aes_256_cbc,sha256}, > {dhe_rsa,aes_128_cbc,sha256}, > {dhe_dss,aes_128_cbc,sha256}, > {rsa,aes_128_cbc,sha256}, > {dhe_rsa,aes_256_cbc,sha}, > {dhe_dss,aes_256_cbc,sha}, > {rsa,aes_256_cbc,sha}, > {dhe_rsa,'3des_ede_cbc',sha}, > {dhe_dss,'3des_ede_cbc',sha}, > {rsa,'3des_ede_cbc',sha}, > {dhe_rsa,aes_128_cbc,sha}, > {dhe_dss,aes_128_cbc,sha}, > {rsa,aes_128_cbc,sha}, > {rsa,rc4_128,sha}, > {rsa,rc4_128,md5}, > {dhe_rsa,des_cbc,sha}, > {rsa,des_cbc,sha}] > end. > > > Thanks, > > -wes > > > > On Fri, Oct 4, 2013 at 8:48 AM, Wes James wrote: > >> How would I do this in the .app.src? >> >> I have: >> >> {application, dbswui, [ >> {description, "database search web ui."}, >> {vsn, "0.1.0"}, >> {modules, []}, >> {registered, []}, >> {applications, [ >> kernel, >> stdlib, >> crypto, >> public_key, >> cowlib, >> cowboy, >> ssl >> ]}, >> {mod, {dbswui_app, []}}, >> {env, []} >> ]}. >> >> I have this from a previous email from you on list. >> >> {ciphers, [{dhe_rsa,aes_256_cbc,sha256}, >> {dhe_dss,aes_256_cbc,sha256}, >> {rsa,aes_256_cbc,sha256}, >> {dhe_rsa,aes_128_cbc,sha256}, >> {dhe_dss,aes_128_cbc,sha256}, >> {rsa,aes_128_cbc,sha256}, >> {dhe_rsa,aes_256_cbc,sha}, >> {dhe_dss,aes_256_cbc,sha}, >> {rsa,aes_256_cbc,sha}, >> {dhe_rsa,'3des_ede_cbc',sha}, >> {dhe_dss,'3des_ede_cbc',sha}, >> {rsa,'3des_ede_cbc',sha}, >> {dhe_rsa,aes_128_cbc,sha}, >> {dhe_dss,aes_128_cbc,sha}, >> {rsa,aes_128_cbc,sha}, >> {rsa,rc4_128,sha}, >> {rsa,rc4_128,md5}, >> {dhe_rsa,des_cbc,sha}, >> {rsa,des_cbc,sha}]} >> >> I tried to put this in the env [] list, but it didn't help. >> >> Thanks, >> >> Wes >> >> >> >> >> On Fri, Oct 4, 2013 at 1:44 AM, Ingela Andin wrote: >> >>> Hi Wes! >>> >>> I have heard from several sources that they have problems connecting >>> with Firefox and Chrome >>> when Elliptic curve cipher suites are enabled. Elliptic curve ciphers >>> where first supported at all in R16 and are by default enabled, although >>> will not be used if the client does not claim to be able to use them. >>> It does seem though that other clients can connect like curl, s_client >>> (openssl), some python client and now opera. I also know that some ECC >>> ciphers are broken in openssl version 1.0.0 and 1.0.0.a. >>> So it seems like it is a client problem that you may workaround by >>> disabling Elliptic Curve cipher suites >>> until the clients get fixed. Also R16B02 fixes an ECC bug so R16B will >>> not be better then R16B02, going >>> back to R15 will work as the ECC ciphers where not supported at all, but >>> I can see other reasons you would not want to do that. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> >>> >>> 2013/10/4 Wes James >>> >>>> Somewhere along the line I've started having issues with self-signed >>>> certs. >>>> >>>> On xubuntu I've: >>>> >>>> recently upgraded chrome and firefox (both having issues) >>>> >>>> recently upgraded cowboy to master >>>> >>>> recently upgrade to 16B02 (compiled then installed) >>>> >>>> I'm having issues accessing sites on https now. I get an error from >>>> firefox, but try to accept but get a security error. On chrome, it just >>>> says it can't get to the site. I then tried opera. I have to confirm some >>>> boxes on opera, but I can finally see the https sites. >>>> >>>> Anyone else having these issues? >>>> >>>> I've tried going back to 16B, but still have the issues so I'm not sure >>>> if it is erlang. I've tried compiling code with 0.8.1 of cowboy with 16B, >>>> but still have the same issues (where it was working fine before), so I'm >>>> not sure where the problem is. >>>> >>>> Thanks, >>>> >>>> Wes >>>> >>>> _______________________________________________ >>>> 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 Sun Oct 6 01:33:49 2013 From: ryankbrown@REDACTED (Ryan Brown) Date: Sat, 5 Oct 2013 17:33:49 -0600 Subject: [erlang-questions] Creating an ssl over TCP ping server In-Reply-To: References: Message-ID: Thanks Wes. This looks like this will do what I need and more. I like the use of cowboy but was honestly looking for a simple example of setting-up a listener without the use of cowboy. Mostly for my edification. Best, Ryan On Friday, October 4, 2013, Wes James wrote: > You can take a look at this to see if it helps: > > https://github.com/comptekki/esysman/blob/master/src/ecom.erl > > I can install this on windows/linux/mac workstations and then send > commands to it from the esysman console. > > -wes > > > On Fri, Oct 4, 2013 at 2:26 PM, Ryan Brown > > wrote: > >> Ok, this seems like it should be a very simple thing to do but I appear >> to be having trouble finding documentation on how to do it without >> incorporating external resources. I just want a simple module where I can >> generate load via https without using a webserver library like ibrowse to >> recieve the messages. >> >> Essentially, I just need something like this: >> >> start(port) -> >> start_webserver_listening_on_port(port), >> receive_loop(). >> >> receive_loop() -> >> whatever. >> >> client(Msg_To_Send) -> >> send_msg_to_server_started_above(Msg_To_Send). >> >> These can/maybe should be, different modules. That's fine. I just want to >> do this in pure erlang and cannot seem to get it worked-out from what I can >> find online. (Feeling dumb) >> >> Thanks in advance! >> >> Ryan >> >> -- >> -rb >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED > 'erlang-questions@REDACTED');> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Sun Oct 6 01:37:54 2013 From: comptekki@REDACTED (Wes James) Date: Sat, 5 Oct 2013 17:37:54 -0600 Subject: [erlang-questions] Creating an ssl over TCP ping server In-Reply-To: References: Message-ID: Actually you could set up an ecom.erl like setup and that is all you would need. I pointed you to ecom.erl since that shows some message passing. Much of the ideas for ecom.erl came from: http://www.erlang.org/doc/getting_started/conc_prog.html -wes On Sat, Oct 5, 2013 at 5:33 PM, Ryan Brown wrote: > Thanks Wes. This looks like this will do what I need and more. I like the > use of cowboy but was honestly looking for a simple example of setting-up a > listener without the use of cowboy. Mostly for my edification. > > Best, > > Ryan > > > On Friday, October 4, 2013, Wes James wrote: > >> You can take a look at this to see if it helps: >> >> https://github.com/comptekki/esysman/blob/master/src/ecom.erl >> >> I can install this on windows/linux/mac workstations and then send >> commands to it from the esysman console. >> >> -wes >> >> >> On Fri, Oct 4, 2013 at 2:26 PM, Ryan Brown wrote: >> >>> Ok, this seems like it should be a very simple thing to do but I appear >>> to be having trouble finding documentation on how to do it without >>> incorporating external resources. I just want a simple module where I can >>> generate load via https without using a webserver library like ibrowse to >>> recieve the messages. >>> >>> Essentially, I just need something like this: >>> >>> start(port) -> >>> start_webserver_listening_on_port(port), >>> receive_loop(). >>> >>> receive_loop() -> >>> whatever. >>> >>> client(Msg_To_Send) -> >>> send_msg_to_server_started_above(Msg_To_Send). >>> >>> These can/maybe should be, different modules. That's fine. I just want >>> to do this in pure erlang and cannot seem to get it worked-out from what I >>> can find online. (Feeling dumb) >>> >>> Thanks in advance! >>> >>> Ryan >>> >>> -- >>> -rb >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > -- > -rb > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryankbrown@REDACTED Sun Oct 6 03:45:22 2013 From: ryankbrown@REDACTED (Ryan Brown) Date: Sat, 5 Oct 2013 19:45:22 -0600 Subject: [erlang-questions] Creating an ssl over TCP ping server In-Reply-To: References: Message-ID: Excellent. Thank you! I somehow missed that point. Best, Ryan On Saturday, October 5, 2013, Wes James wrote: > Actually you could set up an ecom.erl like setup and that is all you would > need. I pointed you to ecom.erl since that shows some message passing. > > Much of the ideas for ecom.erl came from: > > http://www.erlang.org/doc/getting_started/conc_prog.html > > -wes > > > On Sat, Oct 5, 2013 at 5:33 PM, Ryan Brown > > wrote: > >> Thanks Wes. This looks like this will do what I need and more. I like the >> use of cowboy but was honestly looking for a simple example of setting-up a >> listener without the use of cowboy. Mostly for my edification. >> >> Best, >> >> Ryan >> >> >> On Friday, October 4, 2013, Wes James wrote: >> >>> You can take a look at this to see if it helps: >>> >>> https://github.com/comptekki/esysman/blob/master/src/ecom.erl >>> >>> I can install this on windows/linux/mac workstations and then send >>> commands to it from the esysman console. >>> >>> -wes >>> >>> >>> On Fri, Oct 4, 2013 at 2:26 PM, Ryan Brown wrote: >>> >>>> Ok, this seems like it should be a very simple thing to do but I appear >>>> to be having trouble finding documentation on how to do it without >>>> incorporating external resources. I just want a simple module where I can >>>> generate load via https without using a webserver library like ibrowse to >>>> recieve the messages. >>>> >>>> Essentially, I just need something like this: >>>> >>>> start(port) -> >>>> start_webserver_listening_on_port(port), >>>> receive_loop(). >>>> >>>> receive_loop() -> >>>> whatever. >>>> >>>> client(Msg_To_Send) -> >>>> send_msg_to_server_started_above(Msg_To_Send). >>>> >>>> These can/maybe should be, different modules. That's fine. I just want >>>> to do this in pure erlang and cannot seem to get it worked-out from what I >>>> can find online. (Feeling dumb) >>>> >>>> Thanks in advance! >>>> >>>> Ryan >>>> >>>> -- >>>> -rb >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >> >> -- >> -rb >> > > -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From siraaj@REDACTED Sun Oct 6 08:08:33 2013 From: siraaj@REDACTED (Siraaj Khandkar) Date: Sun, 06 Oct 2013 02:08:33 -0400 Subject: [erlang-questions] Module language for Dialyzer? In-Reply-To: <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> References: <524E2C7D.2010901@khandkar.net> <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> Message-ID: <5250FE61.5020509@khandkar.net> There are similarities, but they're different levels of abstraction. Behaviours require one to satisfy an interface, but behaviours are just one use of interfaces. The best analogue to Erlang behaviour is probably the ML functor, where a general module is parametrized by a specific module. I don't think I need to convince anyone that verified [1] contracts between software components is an extremely helpful thing (and Dialyzer helps quite a bit). The new thing that I am asking about is composability of generic interfaces - I want interfaces that live independently of implementations. So just like you have a library of modules and functions that you may choose from to assemble just the module/function that you want, I'd like to be able to define a library of interfaces that I may use to assemble just the _type_ of module I need. Besides composability, this would be a big win for achieving uniformity within a large system (the thing I'm mainly after). Don't stop at just thinking about interfaces as a collection of function specs, the biggest win of interfaces is abstraction of types. An interface defines an opaque type and the operations allowed on that type, so as long as you adhere to the interface and do not violate the opaqueness of the type - you can easily swap concrete implementations of that abstract type. Let's take a concrete example: a dictionary type. stdlib offers several alternatives for a key-value data structure, while conceptually each can be thought of as a dictionary, they all expose a completely different interface. There's already been talk about unifying their interfaces, so wouldn't it be nice to define a uniform "dict" interface and just say: gb_trees.erl -module(gb_trees). -implements([dict]). ... dict.erl -module(dict). -implements([dict]). ... orddict.erl -module(orddict). -implements([dict]). ... ... instead of having to check manually weather the exposed interfaces are compatible? Furthermore, a module can claim to implement several interfaces (note the stringable example from my first email). [1]: I use the term loosely. On 10/04/2013 01:21 AM, Pierre Fenoll wrote: > A module spec can be useful to throw compile-time warnings when implementing generic handlers. > (A generic handler being a collection of functions calling specific functions from another module.) > > Though, a "module signature" already exists (-callback used in pair with -behavior), currently there is no way to check if the other module implements the required functions. > I think it would be a great addition. > >> On 4 oct. 2013, at 03:48, Siraaj Khandkar wrote: >> >> What are the theoretical problems (if any) with an idea of extending Dialyzer with a module language to express composable interfaces in the spirit of SML? >> >> Something along the line of: >> >> dict.esig: >> -signature(dict) :: >> sig >> -type t(K, V) :: opaque(). >> -fun new() -> t(K, V). >> -fun add(t(K, V), K, V) -> t(K, V). >> -fun find(t(K, V), K) -> none | {some, V}. >> ... >> end. >> >> stringable.esig: >> -signature(stringable) :: >> sig >> -type t() :: opaque(). >> -fun to_string(t()) -> string(). >> -fun of_string(string()) -> t(). >> ... >> end. >> >> my_serializable_dict.erl: >> -module(my_serializable_dict). >> -implements([dict, stringable]). >> ... >> >> >> Syntax is not the point of this, so don't get hung-up on it for the purpose of this question - I'm making it up as I type :) From n.oxyde@REDACTED Sun Oct 6 11:45:10 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 6 Oct 2013 11:45:10 +0200 Subject: [erlang-questions] Module language for Dialyzer? In-Reply-To: <5250FE61.5020509@khandkar.net> References: <524E2C7D.2010901@khandkar.net> <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> <5250FE61.5020509@khandkar.net> Message-ID: A module can do all that with behaviours. Just write a dict behaviour. Le 6 oct. 2013 ? 08:08, Siraaj Khandkar a ?crit : > There are similarities, but they're different levels of abstraction. Behaviours require one to satisfy an interface, but behaviours are just one use of interfaces. The best analogue to Erlang behaviour is probably the ML functor, where a general module is parametrized by a specific module. > > I don't think I need to convince anyone that verified [1] contracts between software components is an extremely helpful thing (and Dialyzer helps quite a bit). The new thing that I am asking about is composability of generic interfaces - I want interfaces that live independently of implementations. So just like you have a library of modules and functions that you may choose from to assemble just the module/function that you want, I'd like to be able to define a library of interfaces that I may use to assemble just the _type_ of module I need. Besides composability, this would be a big win for achieving uniformity within a large system (the thing I'm mainly after). > > Don't stop at just thinking about interfaces as a collection of function specs, the biggest win of interfaces is abstraction of types. An interface defines an opaque type and the operations allowed on that type, so as long as you adhere to the interface and do not violate the opaqueness of the type - you can easily swap concrete implementations of that abstract type. > > Let's take a concrete example: a dictionary type. stdlib offers several alternatives for a key-value data structure, while conceptually each can be thought of as a dictionary, they all expose a completely different interface. There's already been talk about unifying their interfaces, so wouldn't it be nice to define a uniform "dict" interface and just say: > > gb_trees.erl > -module(gb_trees). > -implements([dict]). > ... > dict.erl > -module(dict). > -implements([dict]). > ... > orddict.erl > -module(orddict). > -implements([dict]). > ... > > ... instead of having to check manually weather the exposed interfaces are compatible? > > Furthermore, a module can claim to implement several interfaces (note the stringable example from my first email). > > > [1]: I use the term loosely. > > On 10/04/2013 01:21 AM, Pierre Fenoll wrote: >> A module spec can be useful to throw compile-time warnings when implementing generic handlers. >> (A generic handler being a collection of functions calling specific functions from another module.) >> >> Though, a "module signature" already exists (-callback used in pair with -behavior), currently there is no way to check if the other module implements the required functions. >> I think it would be a great addition. >> >>> On 4 oct. 2013, at 03:48, Siraaj Khandkar wrote: >>> >>> What are the theoretical problems (if any) with an idea of extending Dialyzer with a module language to express composable interfaces in the spirit of SML? >>> >>> Something along the line of: >>> >>> dict.esig: >>> -signature(dict) :: >>> sig >>> -type t(K, V) :: opaque(). >>> -fun new() -> t(K, V). >>> -fun add(t(K, V), K, V) -> t(K, V). >>> -fun find(t(K, V), K) -> none | {some, V}. >>> ... >>> end. >>> >>> stringable.esig: >>> -signature(stringable) :: >>> sig >>> -type t() :: opaque(). >>> -fun to_string(t()) -> string(). >>> -fun of_string(string()) -> t(). >>> ... >>> end. >>> >>> my_serializable_dict.erl: >>> -module(my_serializable_dict). >>> -implements([dict, stringable]). >>> ... >>> >>> >>> Syntax is not the point of this, so don't get hung-up on it for the purpose of this question - I'm making it up as I type :) > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Anthony Ramine From siraaj@REDACTED Mon Oct 7 05:51:11 2013 From: siraaj@REDACTED (Siraaj Khandkar) Date: Sun, 06 Oct 2013 23:51:11 -0400 Subject: [erlang-questions] Module language for Dialyzer? In-Reply-To: References: <524E2C7D.2010901@khandkar.net> <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> <5250FE61.5020509@khandkar.net> Message-ID: <52522FAF.9000505@khandkar.net> I hope you're not being serious, because that would be abstraction inversion. Behaviour is a more specific concept. On 10/06/2013 05:45 AM, Anthony Ramine wrote: > A module can do all that with behaviours. > > Just write a dict behaviour. > > Le 6 oct. 2013 ? 08:08, Siraaj Khandkar a ?crit : > >> There are similarities, but they're different levels of abstraction. Behaviours require one to satisfy an interface, but behaviours are just one use of interfaces. The best analogue to Erlang behaviour is probably the ML functor, where a general module is parametrized by a specific module. >> >> I don't think I need to convince anyone that verified [1] contracts between software components is an extremely helpful thing (and Dialyzer helps quite a bit). The new thing that I am asking about is composability of generic interfaces - I want interfaces that live independently of implementations. So just like you have a library of modules and functions that you may choose from to assemble just the module/function that you want, I'd like to be able to define a library of interfaces that I may use to assemble just the _type_ of module I need. Besides composability, this would be a big win for achieving uniformity within a large system (the thing I'm mainly after). >> >> Don't stop at just thinking about interfaces as a collection of function specs, the biggest win of interfaces is abstraction of types. An interface defines an opaque type and the operations allowed on that type, so as long as you adhere to the interface and do not violate the opaqueness of the type - you can easily swap concrete implementations of that abstract type. >> >> Let's take a concrete example: a dictionary type. stdlib offers several alternatives for a key-value data structure, while conceptually each can be thought of as a dictionary, they all expose a completely different interface. There's already been talk about unifying their interfaces, so wouldn't it be nice to define a uniform "dict" interface and just say: >> >> gb_trees.erl >> -module(gb_trees). >> -implements([dict]). >> ... >> dict.erl >> -module(dict). >> -implements([dict]). >> ... >> orddict.erl >> -module(orddict). >> -implements([dict]). >> ... >> >> ... instead of having to check manually weather the exposed interfaces are compatible? >> >> Furthermore, a module can claim to implement several interfaces (note the stringable example from my first email). >> >> >> [1]: I use the term loosely. >> >> On 10/04/2013 01:21 AM, Pierre Fenoll wrote: >>> A module spec can be useful to throw compile-time warnings when implementing generic handlers. >>> (A generic handler being a collection of functions calling specific functions from another module.) >>> >>> Though, a "module signature" already exists (-callback used in pair with -behavior), currently there is no way to check if the other module implements the required functions. >>> I think it would be a great addition. >>> >>>> On 4 oct. 2013, at 03:48, Siraaj Khandkar wrote: >>>> >>>> What are the theoretical problems (if any) with an idea of extending Dialyzer with a module language to express composable interfaces in the spirit of SML? >>>> >>>> Something along the line of: >>>> >>>> dict.esig: >>>> -signature(dict) :: >>>> sig >>>> -type t(K, V) :: opaque(). >>>> -fun new() -> t(K, V). >>>> -fun add(t(K, V), K, V) -> t(K, V). >>>> -fun find(t(K, V), K) -> none | {some, V}. >>>> ... >>>> end. >>>> >>>> stringable.esig: >>>> -signature(stringable) :: >>>> sig >>>> -type t() :: opaque(). >>>> -fun to_string(t()) -> string(). >>>> -fun of_string(string()) -> t(). >>>> ... >>>> end. >>>> >>>> my_serializable_dict.erl: >>>> -module(my_serializable_dict). >>>> -implements([dict, stringable]). >>>> ... >>>> >>>> >>>> Syntax is not the point of this, so don't get hung-up on it for the purpose of this question - I'm making it up as I type :) From n.oxyde@REDACTED Mon Oct 7 09:24:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 7 Oct 2013 09:24:16 +0200 Subject: [erlang-questions] Module language for Dialyzer? In-Reply-To: <52522FAF.9000505@khandkar.net> References: <524E2C7D.2010901@khandkar.net> <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> <5250FE61.5020509@khandkar.net> <52522FAF.9000505@khandkar.net> Message-ID: I am being serious and I don't see how behaviours alone relate more to ML functors than to ML signatures without parameters, as a behaviour can't be parameterized. I also don't see where is the inversion, nor what you can do with ML interfaces that you can't do with behaviours. An example would be great. Le 7 oct. 2013 ? 05:51, Siraaj Khandkar a ?crit : > I hope you're not being serious, because that would be abstraction inversion. Behaviour is a more specific concept. -- Anthony Ramine From dch@REDACTED Mon Oct 7 10:13:59 2013 From: dch@REDACTED (Dave Cottlehuber) Date: Mon, 7 Oct 2013 10:13:59 +0200 Subject: [erlang-questions] Module language for Dialyzer? In-Reply-To: References: <524E2C7D.2010901@khandkar.net> <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> <5250FE61.5020509@khandkar.net> <52522FAF.9000505@khandkar.net> Message-ID: From:?Anthony Ramine Anthony Ramine Reply:?Anthony Ramine n.oxyde@REDACTED Date:?07. Oktober 2013 at 09:24:30 To:?Siraaj Khandkar siraaj@REDACTED Subject:? Re: [erlang-questions] Module language for Dialyzer? > >I am being serious and I don't see how behaviours alone relate more to ML functors than to ML signatures without parameters, as a behaviour can't be parameterized. > >I also don't see where is the inversion, nor what you can do with ML interfaces that you can't do with behaviours. > >An example would be great. > >Le 7 oct. 2013 ? 05:51, Siraaj Khandkar a ?crit : > >> I hope you're not being serious, because that would be abstraction inversion. Behaviour is a more specific concept. > >-- >Anthony Ramine As a practical example, there are many (5? 8?) json encoders in the erlang community, and an additional one as part of R17 via maps (if I read Joe's new book correctly). How would you implement a consistent interface (a protocol) across those today, to allow users to switch between (say) native R17, erlang-only jsx, and nif-driven jiffy? Today I'd guess you would need to write a behaviour and then a bunch of shims between each existing encoder such that it matches the behaviour. Or have an hrl file full of macros. A+ Dave From essen@REDACTED Mon Oct 7 10:23:48 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 07 Oct 2013 10:23:48 +0200 Subject: [erlang-questions] Module language for Dialyzer? In-Reply-To: References: <524E2C7D.2010901@khandkar.net> <3D4D4B93-4056-4452-8672-5B9732C9D4B8@gmail.com> <5250FE61.5020509@khandkar.net> <52522FAF.9000505@khandkar.net> Message-ID: <52526F94.8070509@ninenines.eu> On 10/07/2013 10:13 AM, Dave Cottlehuber wrote: > From: Anthony Ramine Anthony Ramine > Reply: Anthony Ramine n.oxyde@REDACTED > Date: 07. Oktober 2013 at 09:24:30 > To: Siraaj Khandkar siraaj@REDACTED > Subject: Re: [erlang-questions] Module language for Dialyzer? > >> >> I am being serious and I don't see how behaviours alone relate more to ML functors than to ML signatures without parameters, as a behaviour can't be parameterized. >> >> I also don't see where is the inversion, nor what you can do with ML interfaces that you can't do with behaviours. >> >> An example would be great. >> >> Le 7 oct. 2013 ? 05:51, Siraaj Khandkar a ?crit : >> >>> I hope you're not being serious, because that would be abstraction inversion. Behaviour is a more specific concept. >> >> -- >> Anthony Ramine > > As a practical example, there are many (5? 8?) json encoders in the erlang community, and an additional one as part of R17 via maps (if I read Joe's new book correctly). > > How would you implement a consistent interface (a protocol) across those today, to allow users to switch between (say) native R17, erlang-only jsx, and nif-driven jiffy? > > Today I'd guess you would need to write a behaviour and then a bunch of shims between each existing encoder such that it matches the behaviour. Or have an hrl file full of macros. I don't understand. Wasn't it said that the type is opaque? Not the case with JSON libs, you get a structure with a known type that you will want to and will manipulate directly. You don't have a consistent interface for those libs specifically because of that. You could, but it would make manipulating the data too awkward to be any good. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From alexandre.beaulne@REDACTED Mon Oct 7 10:13:29 2013 From: alexandre.beaulne@REDACTED (Alexandre Beaulne) Date: Mon, 7 Oct 2013 16:13:29 +0800 Subject: [erlang-questions] Erlang cluster over a WAN link? Message-ID: Hello everyone, I am working on two tightly coupled (but physically separated) Erlang apps communicating between each other by TCP over a WAN link. I was curious why an Erlang cluster wasn't used in this case and searched around a bit with no clear cut answer. I read that it's generally a bad idea to set up a RabbitMQ cluster using WAN instead of LAN, but if I understand well it has to do with the fact that RabbitMQ lies on the Availability/Partition-tolerance axis of the CAP theorem while in our case we'd be more on the Consistency/Partition-tolerance axis so it might make it more suitable for a cluster? The WAN in question is a leased line that has been solid historically and the number of nodes will probably stay at 2 in the foreseeable future. Anyone here has successfully run an Erlang cluster over a WAN link? Is there good reasons to use a plain vanilla TCP connection rather than an Erlang cluster in this use case? It is sad to have a nice, concurrent Erlang application having to funnel into a single, sequential "TCP" process only to re-branch on the other side of the connection... Thank you very much for you time, Alexandre Beaulne -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Tue Oct 8 09:31:33 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 8 Oct 2013 09:31:33 +0200 Subject: [erlang-questions] self signed certs problem In-Reply-To: References: Message-ID: Hi! As it turns out, it looks no better than that there where several problems, located both on the erlang side and on the other side. Problems that however did not occur when using openssl. You can find a patch for it here that will be included in the next OTP release. https://github.com/IngelaAndin/otp/tree/ia/ssl/ecc-gnutls The good thing is that it should solve all the problems as it will make forinstance gnu-tls take a different path through its code. Regards Ingela Erlang/OTP team - Ericsson AB 2013/10/4 Wes James > I also found a chromium 28.x for xubuntu and installed that. It does not > have the same issues as the current Chrome. Chrome/firefox must be getting > closer/stricter (??) to the ssl specs? > > -wes > > > On Fri, Oct 4, 2013 at 11:11 AM, Wes James wrote: > >> I found where to fix this for now in Lo?c's ranch_ssl.erl: >> >> %% Unfortunately the implementation of elliptic-curve ciphers that >> has >> %% been introduced in R16B01 is incomplete. Depending on the >> particular >> %% client, this can cause the TLS handshake to break during >> key >> %% agreement. Depending on the ssl application version, this >> function >> %% returns a list of all cipher suites that are supported by >> default, >> %% minus the elliptic-curve >> ones. >> >> -spec unbroken_cipher_suites() -> [ssl:erl_cipher_suite()]. >> unbroken_cipher_suites() -> >> case proplists:get_value(ssl_app, ssl:versions()) of >> "5.3" -> >> lists:filter(fun(Suite) -> >> string:left(atom_to_list(element(1, Suite)), 4) =/= "ecdh" >> end, ssl:cipher_suites()); >> _ -> >> %io:format("~n cipher suites: ~p ~n",[ssl:cipher_suites()]), >> %ssl:cipher_suites(), >> >> [{dhe_rsa,aes_256_cbc,sha256}, >> {dhe_dss,aes_256_cbc,sha256}, >> {rsa,aes_256_cbc,sha256}, >> {dhe_rsa,aes_128_cbc,sha256}, >> {dhe_dss,aes_128_cbc,sha256}, >> {rsa,aes_128_cbc,sha256}, >> {dhe_rsa,aes_256_cbc,sha}, >> {dhe_dss,aes_256_cbc,sha}, >> {rsa,aes_256_cbc,sha}, >> {dhe_rsa,'3des_ede_cbc',sha}, >> {dhe_dss,'3des_ede_cbc',sha}, >> {rsa,'3des_ede_cbc',sha}, >> {dhe_rsa,aes_128_cbc,sha}, >> {dhe_dss,aes_128_cbc,sha}, >> {rsa,aes_128_cbc,sha}, >> {rsa,rc4_128,sha}, >> {rsa,rc4_128,md5}, >> {dhe_rsa,des_cbc,sha}, >> {rsa,des_cbc,sha}] >> end. >> >> >> Thanks, >> >> -wes >> >> >> >> On Fri, Oct 4, 2013 at 8:48 AM, Wes James wrote: >> >>> How would I do this in the .app.src? >>> >>> I have: >>> >>> {application, dbswui, [ >>> {description, "database search web ui."}, >>> {vsn, "0.1.0"}, >>> {modules, []}, >>> {registered, []}, >>> {applications, [ >>> kernel, >>> stdlib, >>> crypto, >>> public_key, >>> cowlib, >>> cowboy, >>> ssl >>> ]}, >>> {mod, {dbswui_app, []}}, >>> {env, []} >>> ]}. >>> >>> I have this from a previous email from you on list. >>> >>> {ciphers, [{dhe_rsa,aes_256_cbc,sha256}, >>> {dhe_dss,aes_256_cbc,sha256}, >>> {rsa,aes_256_cbc,sha256}, >>> {dhe_rsa,aes_128_cbc,sha256}, >>> {dhe_dss,aes_128_cbc,sha256}, >>> {rsa,aes_128_cbc,sha256}, >>> {dhe_rsa,aes_256_cbc,sha}, >>> {dhe_dss,aes_256_cbc,sha}, >>> {rsa,aes_256_cbc,sha}, >>> {dhe_rsa,'3des_ede_cbc',sha}, >>> {dhe_dss,'3des_ede_cbc',sha}, >>> {rsa,'3des_ede_cbc',sha}, >>> {dhe_rsa,aes_128_cbc,sha}, >>> {dhe_dss,aes_128_cbc,sha}, >>> {rsa,aes_128_cbc,sha}, >>> {rsa,rc4_128,sha}, >>> {rsa,rc4_128,md5}, >>> {dhe_rsa,des_cbc,sha}, >>> {rsa,des_cbc,sha}]} >>> >>> I tried to put this in the env [] list, but it didn't help. >>> >>> Thanks, >>> >>> Wes >>> >>> >>> >>> >>> On Fri, Oct 4, 2013 at 1:44 AM, Ingela Andin wrote: >>> >>>> Hi Wes! >>>> >>>> I have heard from several sources that they have problems connecting >>>> with Firefox and Chrome >>>> when Elliptic curve cipher suites are enabled. Elliptic curve ciphers >>>> where first supported at all in R16 and are by default enabled, although >>>> will not be used if the client does not claim to be able to use them. >>>> It does seem though that other clients can connect like curl, s_client >>>> (openssl), some python client and now opera. I also know that some ECC >>>> ciphers are broken in openssl version 1.0.0 and 1.0.0.a. >>>> So it seems like it is a client problem that you may workaround by >>>> disabling Elliptic Curve cipher suites >>>> until the clients get fixed. Also R16B02 fixes an ECC bug so R16B will >>>> not be better then R16B02, going >>>> back to R15 will work as the ECC ciphers where not supported at all, >>>> but I can see other reasons you would not want to do that. >>>> >>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> >>>> >>>> >>>> >>>> 2013/10/4 Wes James >>>> >>>>> Somewhere along the line I've started having issues with self-signed >>>>> certs. >>>>> >>>>> On xubuntu I've: >>>>> >>>>> recently upgraded chrome and firefox (both having issues) >>>>> >>>>> recently upgraded cowboy to master >>>>> >>>>> recently upgrade to 16B02 (compiled then installed) >>>>> >>>>> I'm having issues accessing sites on https now. I get an error from >>>>> firefox, but try to accept but get a security error. On chrome, it just >>>>> says it can't get to the site. I then tried opera. I have to confirm some >>>>> boxes on opera, but I can finally see the https sites. >>>>> >>>>> Anyone else having these issues? >>>>> >>>>> I've tried going back to 16B, but still have the issues so I'm not >>>>> sure if it is erlang. I've tried compiling code with 0.8.1 of cowboy with >>>>> 16B, but still have the same issues (where it was working fine before), so >>>>> I'm not sure where the problem is. >>>>> >>>>> Thanks, >>>>> >>>>> Wes >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Tue Oct 8 11:58:17 2013 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 8 Oct 2013 11:58:17 +0200 Subject: [erlang-questions] ANN: locks (beta) - distributed lock manager and leader election Message-ID: <5B8A53C7-2ECF-4D6D-87A1-25E0CE01B12A@feuerlabs.com> https://github.com/uwiger/locks/ Many of you have heard me talk about a lock manager that I've been working on. I think it's now in a state where I can invite people to take it for a spin. Some of you may be interested primarily in the gen_leader-like leader election behavior. You may jump directly to that description below. Note that I consider this a *beta* release. There is a fairly interesting test suite, but the code has not been used in anger yet. The README is (for once) fairly extensive, including a fairly detailed discussion of the verification work done by Thomas Arts back in 1999-2000. I first designed the algorithm back in 1993, but it's taken quite a lot of "hammock time" (to quote Rich Hickey) to fit all details together. A few notes on why I think this implementation is useful: * It detects and resolves deadlocks in a distributed setting, in what we believe is an optimal way, given the assumption that the computers are faster than the network (i.e. trading CPU time for network efficiency). No phantom deadlocks, and no central dependency graph. Note that in some interesting mnesia-based applications, phantom deadlocks have been found to account for some 10-20% overhead in execution time. * Since only true deadlocks are acted upon (either surrendered or leading to transaction abort if requested), transactions do not need to be preemptively restarted, as is the case in deadlock prevention. This means that transaction can be more 'erlang-ish' in their behavior and use side-effects at their leisure. * It supports replicated locks, as well as quorum requirements. The 'lock space' is hierarchical, supporting both read and write locks, as well as upgrade of read locks to write locks. * Locks can be monitored by third parties. The leader election behavior uses this, but it can also be used for debugging. == The locks_leader behavior == Another gen_leader variant? Well, yes. This behavior is closely modeled after gen_leader, but has a few important differences: * The name of the election group is the name of the lock used to resolve elections. This means candidates don't have to have registered names, and there can be multiple candidates on any given node. * Candidates join the group simply by competing for the lock; other candidates discover them through the #locks_info{} notifications, so the candidate list doesn't have to be statically defined. Nodes are easily added at run-time. The classic gen_leader example, gdict, has been implemented on locks_leader: https://github.com/uwiger/locks/tree/master/examples My own plan is to integrate this into the kvdb DBMS, but also to move gproc over to it, making distributed gproc more dynamic and well suited to Erlang's distribution behavior. Feedback, questions and bug reports are highly appreciated! BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From ludovic@REDACTED Tue Oct 8 12:27:22 2013 From: ludovic@REDACTED (ludovic@REDACTED) Date: Tue, 08 Oct 2013 12:27:22 +0200 Subject: [erlang-questions] =?utf-8?q?Comparing_arbitrary-sized_tuples_for?= =?utf-8?q?_equality_=3F?= Message-ID: <64b39311902e5761f40627fddfbe1cec@demblans.com> Hi, In short, i would have some advice about lists vs tuples vs ? for storing hierachical-path data. I'm working on an application where i have to handle items and item groups. In some cases, i must check the group of an item. If at some point i need an item of group group1>subgroup1>subsubgroup1, an item from the group group1>subgroup1>subsubgroup1>deepgroup1 is accepted but an item from group1>subgroup1 isn't because it is not specialized enough. So, at the moment i use lists of atoms to implement groups : Requirements = [ [group1,subgroup1,subsubgroup1] , [group1,subgroup2,othersubsub90] ], MyItem = [ {group,[group1,subgroup1,subsubgroup1,deepgroup1]}, , {id, 123} , {name, <<"myitem">>} ], This is easy because if MyItem's group contains (or equals) any of the Requirements the item is accepted. If no requirement is contained by the item group, the item is rejected : (i'm not writing the base cases there) check(ItemGroup,[R|Requirements]) -> case lists:sublist(ItemGroup,length(R)) of R -> ok ; _ -> not_so_ok end I would like to know if it's a good solution. I have to store items and requirements in mnesia, and groups will be most of the time between 2 and 4 elements. I believe that tuples are more efficients for storage and retrieval, but i'll have to convert them to lists in order to compare requirements and groups of any size. Is it just a matter of what is computed the most : (mnesia work or checking) ? What do you think ? Thanks for reading, Ludovic (this is just an example, the wording "requirement" is not really suited here) From marc@REDACTED Tue Oct 8 13:07:00 2013 From: marc@REDACTED (marc@REDACTED) Date: Tue, 08 Oct 2013 07:07:00 -0400 Subject: [erlang-questions] ANN: locks (beta) - distributed lock manager and leader election In-Reply-To: <5B8A53C7-2ECF-4D6D-87A1-25E0CE01B12A@feuerlabs.com> Message-ID: <20131008110700.5808275.16182.1474@opscode.com> An HTML attachment was scrubbed... URL: From janos.n.hary@REDACTED Tue Oct 8 17:08:54 2013 From: janos.n.hary@REDACTED (Janos Hary) Date: Tue, 8 Oct 2013 17:08:54 +0200 Subject: [erlang-questions] Using socks proxy Message-ID: <006901cec438$4e65f340$eb31d9c0$@gmail.com> All, What shell I do to route my applications network traffic through a socks proxy. The app uses gen_tcp and it's a network client. Thanks for any answer in advance, Janos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Wed Oct 9 21:41:38 2013 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 9 Oct 2013 21:41:38 +0200 Subject: [erlang-questions] ANN: locks (beta) - distributed lock manager and leader election In-Reply-To: <5B8A53C7-2ECF-4D6D-87A1-25E0CE01B12A@feuerlabs.com> References: <5B8A53C7-2ECF-4D6D-87A1-25E0CE01B12A@feuerlabs.com> Message-ID: <58DE6BA8-6418-4CA9-95DD-683B47E62F32@feuerlabs.com> Right after I sent this, of course I found some issues with the locks_leader and recovery from netsplits - It did it, but it wasn't exactly elegant. Did I mention it was a Beta release?? Now it's a lot better, at least in my tests. There is now also some documentation of the locks_leader callback under https://github.com/uwiger/locks/blob/master/examples/doc/test_cb.md and the gdict example actually merges the dictionaries after netsplit, albeit in a very non-optimal way. The real nerds may take a look at the locks_watcher code, https://github.com/uwiger/locks/blob/master/src/locks_watcher.erl#L12 which expands a pseudo-call in the locks_agent into a remote spawn of an interpreted function, which watches for the locks_server to come up on another node. What I think is a bit cool is that the interpreted code is actually implemented as regular code in this module (lines 22-65). The parse_transform lifts and abstracts the code into something that becomes interpreted at runtime. The end result is that locks_agents react immediately to a locks_server starting on another node - no polling required. BR, Ulf W On 8 Oct 2013, at 11:58, Ulf Wiger wrote: > > https://github.com/uwiger/locks/ > > Many of you have heard me talk about a lock manager that I've been working on. > > I think it's now in a state where I can invite people to take it for a spin. Some of you may be > interested primarily in the gen_leader-like leader election behavior. You may jump directly to that > description below. > ... Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From contact@REDACTED Wed Oct 9 20:28:43 2013 From: contact@REDACTED (IEISS Communication) Date: Wed, 9 Oct 2013 21:28:43 +0300 Subject: [erlang-questions] Open source Erlang based FIX Protocol Log Analyzer Message-ID: We have open sourced our product "FIX Protocol Log Analyzer", that helps in analyzing large FIX (Financial Information Exchange) protocol log files. The source code is available at https://github.com/ieiss/fix-log-analyzer Source code includes a sample binary log file containing 2000+ FIX messages, for testing purpose. For product information and screen-shot, visit http://www.ieiss.com/products/fix-log-analyzer More information on FIX Protocol available from http://www.fixtradingcommunity.org/ You can contact us for any queries. We try our best to provide support. _______________________________________ 2013 | IEISS | www.ieiss.com | info@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodolphe@REDACTED Wed Oct 9 17:07:57 2013 From: rodolphe@REDACTED (Rodolphe =?utf-8?Q?Qui=C3=A9deville?=) Date: Wed, 09 Oct 2013 17:07:57 +0200 Subject: [erlang-questions] Xmerl question Message-ID: Hi, This is my first post on this list, I a beginner on erlang with a long experience in other languages like python or perl. When using a xml file with syntax error with xmerl_scan:file the output indicate the line and column number as : 1> xmerl_scan:file('failed.xml'). 2542- fatal: {endtag_does_not_match,{was,request,should_have_been,http}} ** exception exit: {fatal,{{endtag_does_not_match,{was,request, should_have_been,http}}, {file,'failed.xml'}, {line,77}, {col,8}}} The problem is the file failed.xml is composed with a lot of ENTITY so the original file doesn't contains 77 lines, the debug is not easy is this case. Howto dump the final xml really analyzed by xmerl_scan to debug the xml ? Is there any options to pass to xmerl_scan ? I read the doc but can't find the solution. Any helps appreciate Regards; PS : the question was already post on stackoverflow as http://stackoverflow.com/questions/19213242/ -- Rodolphe Qui?deville Expert Tsung - Consulting en performance des SI Tel : 06 13 79 63 41 http://blog.rodolphe.quiedeville.org From max.lapshin@REDACTED Thu Oct 10 00:49:07 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 10 Oct 2013 02:49:07 +0400 Subject: [erlang-questions] Open source Erlang based FIX Protocol Log Analyzer In-Reply-To: References: Message-ID: Nice =) But this way of parsing fix: https://github.com/ieiss/fix-log-analyzer/blob/master/src/log_analyzer.erl#L161 is really bad even for log analyzer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Maxim.Minin@REDACTED Thu Oct 10 08:57:13 2013 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Thu, 10 Oct 2013 08:57:13 +0200 Subject: [erlang-questions] Open source Erlang based FIX Protocol Log Analyzer In-Reply-To: References: Message-ID: Last year as I started to learn erlang, I wrote some erlang fix apps see - https://github.com/MaximMinin: * lib "FixUtils" to convert fix messages in records and back or pretty print them * FixTestErl - an app to write a test scenarios in erlang * FixErl - a little fix engine, that can be use as embeded or standalone app The most important thing for me was, that you can realy read the messages. {out_logon, [{"8","FIXT.1.1"},{"9",""},{"35","A"},{"49","BRKR"},{"56","INVMGR"},{"34",""},{"52",""},{"98","0"},{"108",""},{"1137","0"},{"10",""}]} is not readable for me. I would like to have something like this - beginString=FIX.4.2,bodyLength=72,msgType=testRequest,senderCompID=XXX,targetCompID=YYY,msgSeqNum=3,sendingTime=20131010-06:46:19,testReqID=20131010-06:46:19,checkSum=042. You are welcome to see how I did it on github. Maxim ________________________________ Von: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] Im Auftrag von IEISS Communication Gesendet: Mittwoch, 9. Oktober 2013 20:29 An: erlang-questions@REDACTED Betreff: [erlang-questions] Open source Erlang based FIX Protocol Log Analyzer We have open sourced our product "FIX Protocol Log Analyzer", that helps in analyzing large FIX (Financial Information Exchange) protocol log files. The source code is available at https://github.com/ieiss/fix-log-analyzer Source code includes a sample binary log file containing 2000+ FIX messages, for testing purpose. For product information and screen-shot, visit http://www.ieiss.com/products/fix-log-analyzer More information on FIX Protocol available from http://www.fixtradingcommunity.org/ You can contact us for any queries. We try our best to provide support. _______________________________________ 2013 | IEISS | www.ieiss.com | info@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Oct 10 09:09:08 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 10 Oct 2013 11:09:08 +0400 Subject: [erlang-questions] Open source Erlang based FIX Protocol Log Analyzer In-Reply-To: References: Message-ID: Maxim: 8, 35 and 54 are ok. When you work with fix, you will learn these numbers very fast. Problem is that using lists makes program very, very slower. If there is a code that works with lists for decoding FIX, it is not a production code, it is just a prototype. Our library is rather fast: https://github.com/maxlapshin/fix -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyron.zerafa@REDACTED Thu Oct 10 10:02:03 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Thu, 10 Oct 2013 10:02:03 +0200 Subject: [erlang-questions] Intrusive function intercept Message-ID: Hi, I would like to monitor a process and suspend the execution of certain functions to perform some other computation before. For instance consider a process A which executing the following simple function. test() -> x(), y(), z(). I would like to initiate a process, B, that monitors the execution of A. I want B to: 1) stop A before function y is executed 2) execute some logic 3) resumes the execution of A (by executing Y and Z) So far, I have been following this postand managed to determine when the y() function call was being done, but cannot suspend its execution. Any ideas how I can achieve this? Thanks Tyron -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Oct 10 10:15:35 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 10 Oct 2013 10:15:35 +0200 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: <52566227.6060107@cs.ntua.gr> On 10/10/2013 10:02 AM, Tyron Zerafa wrote: > Hi, > I would like to monitor a process and suspend the execution of > certain functions to perform some other computation before. For instance > consider a process A which executing the following simple function. > > test() -> > x(), > y(), > z(). > > I would like to initiate a process, B, that monitors the execution of A. > I want B to: > 1) stop A before function y is executed > 2) execute some logic > 3) resumes the execution of A (by executing Y and Z) How about changing that code to receive an appropriate message from B at the point(s) you want it to "execute that logic"? Something like: test() -> x(), %% B ! {done,x}, % optionally inform B that x is done receive {cont_msg, Fun} -> Fun() % execute the logic end, y(), z(). Wouldn't that work? Kostis From Maxim.Minin@REDACTED Thu Oct 10 10:28:47 2013 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Thu, 10 Oct 2013 10:28:47 +0200 Subject: [erlang-questions] Open source Erlang based FIX Protocol Log Analyzer In-Reply-To: References: Message-ID: in practice the most people from trading desk don't will learn this tags and if the are some problems and you must tell what was happen, you have to convert the fix messages, so they can understand them. Max, you are right lists can be slower, but they are fast enough to convert more as 5000 per sec on single core. FIX self is very very slower - in our produktion sessions I have seen max 1000 messages per sec. If you have to work with fix messages in your erlang applikation ( compute some values or specify some logic etc ), you must convert messages to records or list and the values to numbers or atoms and so on. Yes if you write the fix engine, that acts as hub, you don't need to do it all and can work with binaries. You are right my projects on github are just prototypes and not fit for production , but if I have to do it for produktion purpose, i would do it in the same way. Maxim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyron.zerafa@REDACTED Thu Oct 10 10:54:05 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Thu, 10 Oct 2013 10:54:05 +0200 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: Yes, we can change the code of the *test* function and use messages; however I was wondering whether there is another approach. Our idea is to build a resource access control system which authorizes access to resources. We came up with the following implementation options: 1) change the Erlang/OTP libraries - ruled out (not an option) 2) perform checks before each access - will have to change our current code and add these checks 3) using monitoring as described in the previous post - monitoring process performs checks and only allow processes to proceed if they've got the correct privilieges Tyron On Thu, Oct 10, 2013 at 10:02 AM, Tyron Zerafa wrote: > Hi, > > I would like to monitor a process and suspend the execution of certain > functions to perform some other computation before. For instance consider a > process A which executing the following simple function. > > test() -> > x(), > y(), > z(). > > I would like to initiate a process, B, that monitors the execution of A. > I want B to: > 1) stop A before function y is executed > 2) execute some logic > 3) resumes the execution of A (by executing Y and Z) > > So far, I have been following this postand managed to determine when the y() function call was being done, but > cannot suspend its execution. Any ideas how I can achieve this? > > Thanks > Tyron > -- Best Regards, Tyron Zerafa -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Thu Oct 10 11:05:50 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 10 Oct 2013 11:05:50 +0200 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: Hi Tyron, There is no way that a monitoring process can interrupt the execution of the monitored process without its cooperation -- the simplest explanation is that since monitoring involves sending a message to another process, the current one continues running before the receiver even gets to check its mailbox. Besides introducing checks directly in your code, I can see two more options: 4) interpret the code like the debugger does - this is not something I'd do in a production setting 5) change your code to be "rule based": test() -> execute[fun x/0, fun y/0, funz/0]. Then execute/1 can be a generic function that can do all kinds of checks before and after each call. The advantage from #2 is that this handling is in one place instead of spread over the codebase. best regards, Vlad On Thu, Oct 10, 2013 at 10:54 AM, Tyron Zerafa wrote: > Yes, we can change the code of the *test* function and use messages; > however I was wondering whether there is another approach. Our idea is to > build a resource access control system which authorizes access to > resources. We came up with the following implementation options: > 1) change the Erlang/OTP libraries - ruled out (not an option) > 2) perform checks before each access - will have to change our current > code and add these checks > 3) using monitoring as described in the previous post - monitoring > process performs checks and only allow processes to proceed if they've got > the correct privilieges > > Tyron > > > On Thu, Oct 10, 2013 at 10:02 AM, Tyron Zerafa wrote: > >> Hi, >> >> I would like to monitor a process and suspend the execution of >> certain functions to perform some other computation before. For instance >> consider a process A which executing the following simple function. >> >> test() -> >> x(), >> y(), >> z(). >> >> I would like to initiate a process, B, that monitors the execution of A. >> I want B to: >> 1) stop A before function y is executed >> 2) execute some logic >> 3) resumes the execution of A (by executing Y and Z) >> >> So far, I have been following this postand managed to determine when the y() function call was being done, but >> cannot suspend its execution. Any ideas how I can achieve this? >> >> Thanks >> Tyron >> > > > > -- > Best Regards, > Tyron Zerafa > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Thu Oct 10 11:13:45 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 10 Oct 2013 11:13:45 +0200 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: <52566FC9.3090600@gmail.com> On 2013-10-10 10:54 , Tyron Zerafa wrote: > Yes, we can change the code of the /test/ function and use messages; > however I was wondering whether there is another approach. Our idea is > to build a resource access control system which authorizes access to > resources. We came up with the following implementation options: > 1) change the Erlang/OTP libraries - ruled out (not an option) > 2) perform checks before each access - will have to change our current > code and add these checks > 3) using monitoring as described in the previous post - monitoring > process performs checks and only allow processes to proceed if they've > got the correct privilieges If you're not afraid of getting down and dirty, there's another possibility that doesn't require any source code changes, and which guarantees that you check all resource accesses: rewrite the BEAM bytecode of modules at load time, inserting checks automatically. /Richard From olivier.boudeville@REDACTED Thu Oct 10 11:56:17 2013 From: olivier.boudeville@REDACTED (Olivier BOUDEVILLE) Date: Thu, 10 Oct 2013 11:56:17 +0200 Subject: [erlang-questions] "Fat" BEAMs? Message-ID: Hi, Let's suppose that, thanks to a parse-transform, we fetched recursively from other modules most if not all code explicitly callable from a given module, so that the full code (ultimately calling only basic language constructs and BIFs) ends up in a single (presumably big, unfolded, possibly inlined) AST. Then, in the prospect of native compilation (HiPe, possibly others like ErLLVM), I imagine that not only we should get rid of the overhead of inter-module calls, but we would also give to the compiler the best full view on which it could operate and generate the best code it could manage? Has this approach already been attempted? Would it have some potential interest? Thanks in advance for any hint, Best regards, Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Thu Oct 10 12:34:13 2013 From: tony@REDACTED (Tony Rogvall) Date: Thu, 10 Oct 2013 12:34:13 +0200 Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: References: Message-ID: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> Maybe give https://github.com/tonyrog/inline a try? /Tony On 10 okt 2013, at 11:56, Olivier BOUDEVILLE wrote: > Hi, > > Let's suppose that, thanks to a parse-transform, we fetched recursively from other modules most if not all code explicitly callable from a given module, so that the full code (ultimately calling only basic language constructs and BIFs) ends up in a single (presumably big, unfolded, possibly inlined) AST. > > Then, in the prospect of native compilation (HiPe, possibly others like ErLLVM), I imagine that not only we should get rid of the overhead of inter-module calls, but we would also give to the compiler the best full view on which it could operate and generate the best code it could manage? > > Has this approach already been attempted? Would it have some potential interest? > > Thanks in advance for any hint, > Best regards, > > Olivier. > --------------------------- > Olivier Boudeville > > EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France > D?partement SINETICS, groupe ASICS (I2A), bureau B-226 > Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 > > > Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. > > Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. > > Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. > ____________________________________________________ > > This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. > > If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. > > E-mail communication cannot be guaranteed to be timely secure, error or virus-free. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Thu Oct 10 13:09:02 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 10 Oct 2013 13:09:02 +0200 Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> Message-ID: <52568ACE.7030805@gmail.com> This functionality has existed in Igor for the last 15 years or so: http://www.erlang.org/doc/man/igor.html#parse_transform-2 The main drawback (apart from the obvious code duplication if you include the same module in a lot of other modules) is of course that reloading a single module of the included ones won't have any effect; you have to replace the whole blob each time. /Richard On 2013-10-10 12:34 , Tony Rogvall wrote: > Maybe give https://github.com/tonyrog/inline a try? > > /Tony > > On 10 okt 2013, at 11:56, Olivier BOUDEVILLE > wrote: > >> Hi, >> >> Let's suppose that, thanks to a parse-transform, we fetched >> recursively from other modules most if not all code explicitly >> callable from a given module, so that the full code (ultimately >> calling only basic language constructs and BIFs) ends up in a single >> (presumably big, unfolded, possibly inlined) AST. >> >> Then, in the prospect of native compilation (HiPe, possibly others >> like ErLLVM), I imagine that not only we should get rid of the >> overhead of inter-module calls, but we would also give to the compiler >> the best full view on which it could operate and generate the best >> code it could manage? >> >> Has this approach already been attempted? Would it have some potential >> interest? >> >> Thanks in advance for any hint, >> Best regards, >> >> Olivier. >> --------------------------- >> Olivier Boudeville >> >> EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >> D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >> Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 >> 47 65 27 13 >> >> >> Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont >> ?tablis ? l'intention exclusive des destinataires et les informations >> qui y figurent sont strictement confidentielles. Toute utilisation de >> ce Message non conforme ? sa destination, toute diffusion ou toute >> publication totale ou partielle, est interdite sauf autorisation expresse. >> >> Si vous n'?tes pas le destinataire de ce Message, il vous est interdit >> de le copier, de le faire suivre, de le divulguer ou d'en utiliser >> tout ou partie. Si vous avez re?u ce Message par erreur, merci de le >> supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en >> garder aucune trace sur quelque support que ce soit. Nous vous >> remercions ?galement d'en avertir imm?diatement l'exp?diteur par >> retour du message. >> >> Il est impossible de garantir que les communications par messagerie >> ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de >> toute erreur ou virus. >> ____________________________________________________ >> >> This message and any attachments (the 'Message') are intended solely >> for the addressees. The information contained in this Message is >> confidential. Any use of information contained in this Message not in >> accord with its purpose, any dissemination or disclosure, either whole >> or partial, is prohibited except formal approval. >> >> If you are not the addressee, you may not copy, forward, disclose or >> use any part of it. If you have received this message in error, please >> delete it and all copies from your system and notify the sender >> immediately by return message. >> >> E-mail communication cannot be guaranteed to be timely secure, error >> or virus-free. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, > user and system errors happen, and minute changes may be unnoticeable > and difficult to fix" > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From olivier.boudeville@REDACTED Thu Oct 10 13:22:29 2013 From: olivier.boudeville@REDACTED (Olivier BOUDEVILLE) Date: Thu, 10 Oct 2013 13:22:29 +0200 Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> Message-ID: Indeed! Additionally, it is quite recent. It could be interesting to measure the speed-up that can actually be obtained, possibly in various settings (native or not, with the various compilers, etc.); maybe this could also allow to have Erlang shine a bit more in some benchmarks! Thanks for the pointer (will definitively try it), Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 tony@REDACTED 10/10/2013 12:34 A olivier.boudeville@REDACTED cc erlang-questions@REDACTED Objet Re: [erlang-questions] "Fat" BEAMs? Maybe give https://github.com/tonyrog/inline a try? /Tony On 10 okt 2013, at 11:56, Olivier BOUDEVILLE wrote: Hi, Let's suppose that, thanks to a parse-transform, we fetched recursively from other modules most if not all code explicitly callable from a given module, so that the full code (ultimately calling only basic language constructs and BIFs) ends up in a single (presumably big, unfolded, possibly inlined) AST. Then, in the prospect of native compilation (HiPe, possibly others like ErLLVM), I imagine that not only we should get rid of the overhead of inter-module calls, but we would also give to the compiler the best full view on which it could operate and generate the best code it could manage? Has this approach already been attempted? Would it have some potential interest? Thanks in advance for any hint, Best regards, Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.boudeville@REDACTED Thu Oct 10 13:48:32 2013 From: olivier.boudeville@REDACTED (Olivier BOUDEVILLE) Date: Thu, 10 Oct 2013 13:48:32 +0200 Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: <52568ACE.7030805@gmail.com> References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> <52568ACE.7030805@gmail.com> Message-ID: Hello again, Thanks Richard, another solution indeed. 15 years ago, wow! Regarding the replacement drawback, it could be seen also as a nice feature, allowing an indefinite number of versions of the same intermediate, inlined modules to coexist peacefully. Thanks again, Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 carlsson.richard@REDACTED Envoy? par : erlang-questions-bounces@REDACTED 10/10/2013 13:09 A erlang-questions@REDACTED cc Objet Re: [erlang-questions] "Fat" BEAMs? This functionality has existed in Igor for the last 15 years or so: http://www.erlang.org/doc/man/igor.html#parse_transform-2 The main drawback (apart from the obvious code duplication if you include the same module in a lot of other modules) is of course that reloading a single module of the included ones won't have any effect; you have to replace the whole blob each time. /Richard On 2013-10-10 12:34 , Tony Rogvall wrote: > Maybe give https://github.com/tonyrog/inline a try? > > /Tony > > On 10 okt 2013, at 11:56, Olivier BOUDEVILLE > wrote: > >> Hi, >> >> Let's suppose that, thanks to a parse-transform, we fetched >> recursively from other modules most if not all code explicitly >> callable from a given module, so that the full code (ultimately >> calling only basic language constructs and BIFs) ends up in a single >> (presumably big, unfolded, possibly inlined) AST. >> >> Then, in the prospect of native compilation (HiPe, possibly others >> like ErLLVM), I imagine that not only we should get rid of the >> overhead of inter-module calls, but we would also give to the compiler >> the best full view on which it could operate and generate the best >> code it could manage? >> >> Has this approach already been attempted? Would it have some potential >> interest? >> >> Thanks in advance for any hint, >> Best regards, >> >> Olivier. >> --------------------------- >> Olivier Boudeville >> >> EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >> D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >> Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 >> 47 65 27 13 >> >> >> Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont >> ?tablis ? l'intention exclusive des destinataires et les informations >> qui y figurent sont strictement confidentielles. Toute utilisation de >> ce Message non conforme ? sa destination, toute diffusion ou toute >> publication totale ou partielle, est interdite sauf autorisation expresse. >> >> Si vous n'?tes pas le destinataire de ce Message, il vous est interdit >> de le copier, de le faire suivre, de le divulguer ou d'en utiliser >> tout ou partie. Si vous avez re?u ce Message par erreur, merci de le >> supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en >> garder aucune trace sur quelque support que ce soit. Nous vous >> remercions ?galement d'en avertir imm?diatement l'exp?diteur par >> retour du message. >> >> Il est impossible de garantir que les communications par messagerie >> ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de >> toute erreur ou virus. >> ____________________________________________________ >> >> This message and any attachments (the 'Message') are intended solely >> for the addressees. The information contained in this Message is >> confidential. Any use of information contained in this Message not in >> accord with its purpose, any dissemination or disclosure, either whole >> or partial, is prohibited except formal approval. >> >> If you are not the addressee, you may not copy, forward, disclose or >> use any part of it. If you have received this message in error, please >> delete it and all copies from your system and notify the sender >> immediately by return message. >> >> E-mail communication cannot be guaranteed to be timely secure, error >> or virus-free. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, > user and system errors happen, and minute changes may be unnoticeable > and difficult to fix" > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Thu Oct 10 15:48:42 2013 From: comptekki@REDACTED (Wes James) Date: Thu, 10 Oct 2013 07:48:42 -0600 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: Why are you trying to monitor with B. Why not just do: test() -> x(), do_something(), y(), z(). -wes On Thu, Oct 10, 2013 at 2:02 AM, Tyron Zerafa wrote: > Hi, > > I would like to monitor a process and suspend the execution of certain > functions to perform some other computation before. For instance consider a > process A which executing the following simple function. > > test() -> > x(), > y(), > z(). > > I would like to initiate a process, B, that monitors the execution of A. > I want B to: > 1) stop A before function y is executed > 2) execute some logic > 3) resumes the execution of A (by executing Y and Z) > > So far, I have been following this postand managed to determine when the y() function call was being done, but > cannot suspend its execution. Any ideas how I can achieve this? > > Thanks > Tyron > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baliulia@REDACTED Thu Oct 10 16:15:25 2013 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Thu, 10 Oct 2013 16:15:25 +0200 Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> Message-ID: <5256B67D.4030407@gmail.com> On 10/10/2013 01:22 PM, Olivier BOUDEVILLE wrote: > It could be interesting to measure the speed-up that can actually be > obtained, possibly in various settings (native or not, with the > various compilers, etc.); maybe this could also allow to have Erlang > shine a bit more in some benchmarks! > > Thanks for the pointer (will definitively try it), Please share your results if possible! I am also considering using some extreme inlining for optimising parts of my code, but so far never got round to evaluating whether it's worth the effort. -- Ignas From ulf@REDACTED Thu Oct 10 17:13:32 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 10 Oct 2013 17:13:32 +0200 Subject: [erlang-questions] =?iso-8859-1?q?=D6rebro_Functional_Programmers?= =?iso-8859-1?q?=2C_Erlounge_Oct_31?= Message-ID: <8F623FF3-A33B-4239-AEC5-ED4F5A79184D@feuerlabs.com> Some of you may recall that we had an Erlang Users Group Meeting in ?rebro last year? It was such a raging success (three of us met and had great conversation over beer), that we decided to take it to the next level. On October 31, we will have a first meeting of the ?rebro Functional Programmers group. http://www.meetup.com/Orebro-Functional-Programmers/events/143274802/ The concept is borrowed from the Stockholm Erlounges, where different companies would take turns hosting the event - first one out will be the consulting firm Sogeti. As Rockstar Invited Speaker we have secured John Hughes, and representing the locals, Ulf Wiger will give a talk. The topic of these meetings will not be specifically Erlang. Since we know of only two Erlang programmers (+ one ex Erlang programmer, and apparently an "Elixir apprentice") in ?rebro, we will try to broaden the scope and touch on cool modern technologies with a certain bent towards functional programming. Thus, we will not assume prior Erlang (or even functional programming) knowledge at these events. If you live nearby, or otherwise have a secret urge to visit ?rebro in October, you're welcome to sign up. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From nem@REDACTED Thu Oct 10 21:47:55 2013 From: nem@REDACTED (Geoff Cant) Date: Thu, 10 Oct 2013 12:47:55 -0700 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: <52566FC9.3090600@gmail.com> References: <52566FC9.3090600@gmail.com> Message-ID: The 'int' module in the debugger application might be able to help here. It performs the instrumentation (re-compiles your module from debug_info[1] with breakpoints and so on) and manages the execution of instrumented code for you. http://www.erlang.org/doc/man/int.html I think that using 'int' as the basis for building a production system is crazy, but it'd be interesting to try out. -Geoff [1] ALWAYS compile with debug_info.[2] [2] Why is that not the default? I have never not wanted it. On 2013-10-10, at 02:13 , Richard Carlsson wrote: > On 2013-10-10 10:54 , Tyron Zerafa wrote: >> Yes, we can change the code of the /test/ function and use messages; >> however I was wondering whether there is another approach. Our idea is >> to build a resource access control system which authorizes access to >> resources. We came up with the following implementation options: >> 1) change the Erlang/OTP libraries - ruled out (not an option) >> 2) perform checks before each access - will have to change our current >> code and add these checks >> 3) using monitoring as described in the previous post - monitoring >> process performs checks and only allow processes to proceed if they've >> got the correct privilieges > > If you're not afraid of getting down and dirty, there's another possibility that doesn't require any source code changes, and which guarantees that you check all resource accesses: rewrite the BEAM bytecode of modules at load time, inserting checks automatically. > > /Richard From ulf@REDACTED Thu Oct 10 21:57:14 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 10 Oct 2013 21:57:14 +0200 Subject: [erlang-questions] ANN: locks (beta) - distributed lock manager and leader election In-Reply-To: <7636F9A1-DF58-41FB-93C0-647253570288@erlang.geek.nz> References: <5B8A53C7-2ECF-4D6D-87A1-25E0CE01B12A@feuerlabs.com> <58DE6BA8-6418-4CA9-95DD-683B47E62F32@feuerlabs.com> <7636F9A1-DF58-41FB-93C0-647253570288@erlang.geek.nz> Message-ID: Hi Geoff, For the time being, I included Thomas Arts's old description of the algorithm in the README.md (the "Verification" chapter). That description deals with the locking algorith. The locks_leader behavior simply has all candidates trying to claim a specific lock on every visible node (it would be possible to add an option to restrict the list of candidate nodes). Since the locks_agent will tell its client (a candidate) which other agents & clients are vying for the lock, all candidates can be derived from the lock queue. And since the algorithm will resolve deadlocks through 'lock surrender', one agent will always end up holding all locks*, and thus becomes the leader. Workers simply monitor the lock, which means they also get the lock updates. Once they get an update, they find any new candidate and send it a message, introducing themselves as workers. BR, Ulf * It's essentially the same lock on all nodes, but each lock+node instance counts as one lock. This is also why a deadlock situation can occur. On 10 Oct 2013, at 21:48, Geoff Cant wrote: > Hi Ulf, do you have a synopsis of the protocol/distributed algorithm the locks_agent run? > > I had a lot of trouble trying to figure out which protocol/algorithm the gen_leader variants were using the last time I looked at them. Having a description of which algorithm they were implementing (say 'asynchronous bully leader election') and the modifications they made (protocol messages to change the candidate set) would be a significant help to understanding the codebase. > > -Geoff > > On 2013-10-09, at 12:41 , Ulf Wiger wrote: > >> >> Right after I sent this, of course I found some issues with the locks_leader and recovery from netsplits - It did it, but it wasn't exactly elegant. Did I mention it was a Beta release?? >> >> Now it's a lot better, at least in my tests. >> >> There is now also some documentation of the locks_leader callback under >> https://github.com/uwiger/locks/blob/master/examples/doc/test_cb.md >> >> and the gdict example actually merges the dictionaries after netsplit, albeit in a very non-optimal way. >> >> >> The real nerds may take a look at the locks_watcher code, >> >> https://github.com/uwiger/locks/blob/master/src/locks_watcher.erl#L12 >> >> which expands a pseudo-call in the locks_agent into a remote spawn of an interpreted >> function, which watches for the locks_server to come up on another node. >> >> What I think is a bit cool is that the interpreted code is actually implemented as regular >> code in this module (lines 22-65). The parse_transform lifts and abstracts the code into >> something that becomes interpreted at runtime. >> >> The end result is that locks_agents react immediately to a locks_server starting on >> another node - no polling required. >> >> BR, >> Ulf W > > > > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From ulf@REDACTED Thu Oct 10 22:00:31 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 10 Oct 2013 22:00:31 +0200 Subject: [erlang-questions] ANN: locks (beta) - distributed lock manager and leader election In-Reply-To: References: <5B8A53C7-2ECF-4D6D-87A1-25E0CE01B12A@feuerlabs.com> <58DE6BA8-6418-4CA9-95DD-683B47E62F32@feuerlabs.com> <7636F9A1-DF58-41FB-93C0-647253570288@erlang.geek.nz> Message-ID: I should mention that the configuration of the locks_leader that I've played with so far is where each candidate is anonymous. Naturally, since I hadn't tested the config where there's one registered candidate on each node, that doesn't work yet. Minor bugs that will be fixed soon. BR, Ulf On 10 Oct 2013, at 21:57, Ulf Wiger wrote: > > Hi Geoff, > > For the time being, I included Thomas Arts's old description of the algorithm in the README.md (the "Verification" chapter). > > That description deals with the locking algorith. The locks_leader behavior simply has all candidates trying to claim a specific lock on every visible node (it would be possible to add an option to restrict the list of candidate nodes). Since the locks_agent will tell its client (a candidate) which other agents & clients are vying for the lock, all candidates can be derived from the lock queue. And since the algorithm will resolve deadlocks through 'lock surrender', one agent will always end up holding all locks*, and thus becomes the leader. > > Workers simply monitor the lock, which means they also get the lock updates. Once they get an update, they find any new candidate and send it a message, introducing themselves as workers. > > BR, > Ulf > > * It's essentially the same lock on all nodes, but each lock+node instance counts as one lock. This is also why a deadlock situation can occur. > > On 10 Oct 2013, at 21:48, Geoff Cant wrote: > >> Hi Ulf, do you have a synopsis of the protocol/distributed algorithm the locks_agent run? >> >> I had a lot of trouble trying to figure out which protocol/algorithm the gen_leader variants were using the last time I looked at them. Having a description of which algorithm they were implementing (say 'asynchronous bully leader election') and the modifications they made (protocol messages to change the candidate set) would be a significant help to understanding the codebase. >> >> -Geoff >> >> On 2013-10-09, at 12:41 , Ulf Wiger wrote: >> >>> >>> Right after I sent this, of course I found some issues with the locks_leader and recovery from netsplits - It did it, but it wasn't exactly elegant. Did I mention it was a Beta release?? >>> >>> Now it's a lot better, at least in my tests. >>> >>> There is now also some documentation of the locks_leader callback under >>> https://github.com/uwiger/locks/blob/master/examples/doc/test_cb.md >>> >>> and the gdict example actually merges the dictionaries after netsplit, albeit in a very non-optimal way. >>> >>> >>> The real nerds may take a look at the locks_watcher code, >>> >>> https://github.com/uwiger/locks/blob/master/src/locks_watcher.erl#L12 >>> >>> which expands a pseudo-call in the locks_agent into a remote spawn of an interpreted >>> function, which watches for the locks_server to come up on another node. >>> >>> What I think is a bit cool is that the interpreted code is actually implemented as regular >>> code in this module (lines 22-65). The parse_transform lifts and abstracts the code into >>> something that becomes interpreted at runtime. >>> >>> The end result is that locks_agents react immediately to a locks_server starting on >>> another node - no polling required. >>> >>> BR, >>> Ulf W >> >> >> >> >> > > 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 Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From john.ashmun@REDACTED Fri Oct 11 04:34:57 2013 From: john.ashmun@REDACTED (John R. Ashmun) Date: Thu, 10 Oct 2013 19:34:57 -0700 Subject: [erlang-questions] Running edoc:application( ) on Windows 7, but it's not finding any modules Message-ID: Hi. I have a new application, MIX, the directories of which are organized as recommended in Erlang And OTP In Action, e.g., given that my Erlang-y home directory is c:\Program Files\erl5.9\usr\john the application's top level is "MIX" in my home directory, and in it are doc ebin include priv src There are two modules in src (and the corresponding .beam files in ebin, along with MIX.app). There is also an overview.edoc file in doc. I was hoping that, from a command prompt with MIX as its current directory, that running werl -pa ebin and using edoc:application( 'MIX', ".", [] ). in the shell would find these modules (which are named 'MIX' and 'M') and generate some documentation, but this doesn't succeed, although a nice, rather empty Overview is generated. On the other hand, using edoc:files( [ "src/MIX.erl", "src/M.erl" ] ). does produce documentation about the modules, but files( ) doesn't make use of the overview.edoc file, so the Overview is really empty. I expect that I am just not running the right command from the right location, but after three hours of trying everything I could think of, I need help, please. John Ashmun -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Fri Oct 11 08:08:59 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 10 Oct 2013 23:08:59 -0700 (PDT) Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> Message-ID: <1381471739.99542.YahooMailNeo@web140101.mail.bf1.yahoo.com> Hi Olivier, Regarding cross-module optimization and inlining, have a look at these: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.4909 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.6496 Appendix A of the second paper made me realize how much work is going on inside mnesia. For one benchmark, that algorithm decided to inline?mnesia:dirty_write/2?something like 10 levels deep through 8 modules, resulting in a 1000-line function. The whole topic needs more work though. Best, Thomas On Thursday, October 10, 2013 1:23 PM, Olivier BOUDEVILLE wrote: Indeed! Additionally, it is quite recent. > >It could be interesting to measure the speed-up that can actually be obtained, possibly in various settings (native or not, with the various compilers, etc.); maybe this could also allow to have Erlang shine a bit more in some benchmarks! > >Thanks for the pointer (will definitively try it), > >Olivier. >--------------------------- >Olivier Boudeville > >EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 > > > >tony@REDACTED >10/10/2013 12:34 A olivier.boudeville@REDACTED >cc erlang-questions@REDACTED >Objet Re: [erlang-questions] "Fat" BEAMs? > > > > >Maybe give https://github.com/tonyrog/inlinea try? > >/Tony > >On 10 okt 2013, at 11:56, Olivier BOUDEVILLE wrote: > >Hi, > >Let's suppose that, thanks to a parse-transform, we fetched recursively from other modules most if not all code explicitly callable from a given module, so that the full code (ultimately calling only basic language constructs and BIFs) ends up in a single (presumably big, unfolded, possibly inlined) AST. > >Then, in ?the prospect of native compilation (HiPe, possibly others like ErLLVM), I imagine that not only we should get rid of the overhead of inter-module calls, but we would also give to the compiler the best full view on which it could operate and generate the best code it could manage? > >Has this approach already been attempted? Would it have some potential interest? > >Thanks in advance for any hint, >Best regards, > >Olivier. >--------------------------- >Olivier Boudeville > >EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 > > >Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. >Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. >Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. >____________________________________________________ >This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. >If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. >E-mail communication cannot be guaranteed to be timely secure, error or virus-free. >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > >"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" > > > > > > >Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. >Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. >Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. >____________________________________________________ >This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. >If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. >E-mail communication cannot be guaranteed to be timely secure, error or virus-free. > >_______________________________________________ >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 Fri Oct 11 08:19:17 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 10 Oct 2013 23:19:17 -0700 (PDT) Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: <1381471739.99542.YahooMailNeo@web140101.mail.bf1.yahoo.com> References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> <1381471739.99542.YahooMailNeo@web140101.mail.bf1.yahoo.com> Message-ID: <1381472357.39305.YahooMailNeo@web140105.mail.bf1.yahoo.com> I should also add that Frej Drejhammar's work on a tracing JIT emulator would enable cross-module inlining etc in a somewhat different context, so it will be quite interesting to see what comes from that. I've only seen a couple of conference presentations yet, looking forward to more. Best, Thomas On Friday, October 11, 2013 8:09 AM, Thomas Lindgren wrote: Hi Olivier, > > >Regarding cross-module optimization and inlining, have a look at these: > > >http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.4909 > >http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.6496 > > > >Appendix A of the second paper made me realize how much work is going on inside mnesia. For one benchmark, that algorithm decided to inline?mnesia:dirty_write/2?something like 10 levels deep through 8 modules, resulting in a 1000-line function. The whole topic needs more work though. > > >Best, >Thomas > > > >On Thursday, October 10, 2013 1:23 PM, Olivier BOUDEVILLE wrote: > >Indeed! Additionally, it is quite recent. >> >>It could be interesting to measure the speed-up that can actually be obtained, possibly in various settings (native or not, with the various compilers, etc.); maybe this could also allow to have Erlang shine a bit more in some benchmarks! >> >>Thanks for the pointer (will definitively try it), >> >>Olivier. >>--------------------------- >>Olivier Boudeville >> >>EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >>D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >>Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 >> >> >> >>tony@REDACTED >>10/10/2013 12:34 A olivier.boudeville@REDACTED >>cc erlang-questions@REDACTED >>Objet Re: [erlang-questions] "Fat" BEAMs? >> >> >> >> >>Maybe give https://github.com/tonyrog/inlinea try? >> >>/Tony >> >>On 10 okt 2013, at 11:56, Olivier BOUDEVILLE wrote: >> >>Hi, >> >>Let's suppose that, thanks to a parse-transform, we fetched recursively from other modules most if not all code explicitly callable from a given module, so that the full code (ultimately calling only basic language constructs and BIFs) ends up in a single (presumably big, unfolded, possibly inlined) AST. >> >>Then, in ?the prospect of native compilation (HiPe, possibly others like ErLLVM), I imagine that not only we should get rid of the overhead of inter-module calls, but we would also give to the compiler the best full view on which it could operate and generate the best code it could manage? >> >>Has this approach already been attempted? Would it have some potential interest? >> >>Thanks in advance for any hint, >>Best regards, >> >>Olivier. >>--------------------------- >>Olivier Boudeville >> >>EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >>D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >>Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 >> >> >>Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. >>Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. >>Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. >>____________________________________________________ >>This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. >>If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. >>E-mail communication cannot be guaranteed to be timely secure, error or virus-free. >>_______________________________________________ >>erlang-questions mailing list >>erlang-questions@REDACTED >>http://erlang.org/mailman/listinfo/erlang-questions >> >>"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" >> >> >> >> >> >> >>Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. >>Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. >>Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. >>____________________________________________________ >>This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. >>If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. >>E-mail communication cannot be guaranteed to be timely secure, error or virus-free. >> >>_______________________________________________ >>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 tyron.zerafa@REDACTED Fri Oct 11 11:19:28 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Fri, 11 Oct 2013 11:19:28 +0200 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: First - I do not want to clutter my code with *do_something(); *I need this perform this call multiple times at different places. Second -* do_something()* performs some access control logic, *test() *is any other function accessing resources. Ideally, developers writing *test()*functions wouldn't have to worry about access control (this should be hidden). On Thu, Oct 10, 2013 at 3:48 PM, Wes James wrote: > Why are you trying to monitor with B. Why not just do: > > test() -> > x(), > do_something(), > y(), > z(). > > -wes > > > > On Thu, Oct 10, 2013 at 2:02 AM, Tyron Zerafa wrote: > >> Hi, >> >> I would like to monitor a process and suspend the execution of >> certain functions to perform some other computation before. For instance >> consider a process A which executing the following simple function. >> >> test() -> >> x(), >> y(), >> z(). >> >> I would like to initiate a process, B, that monitors the execution of A. >> I want B to: >> 1) stop A before function y is executed >> 2) execute some logic >> 3) resumes the execution of A (by executing Y and Z) >> >> So far, I have been following this postand managed to determine when the y() function call was being done, but >> cannot suspend its execution. Any ideas how I can achieve this? >> >> Thanks >> Tyron >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Best Regards, Tyron Zerafa -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Oct 11 11:30:31 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 11 Oct 2013 11:30:31 +0200 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: <5257C537.7060200@ninenines.eu> do_something() could be added automatically with a parse_transform though. Nobody would have to worry about it and the code wouldn't be cluttered. On 10/11/2013 11:19 AM, Tyron Zerafa wrote: > First - I do not want to clutter my code with /do_something(); /I need > this perform this call multiple times at different places. > Second -/ do_something()/ performs some access control logic, /test() > /is any other function accessing resources. Ideally, developers writing > /test()/ functions wouldn't have to worry about access control (this > should be hidden). > > > On Thu, Oct 10, 2013 at 3:48 PM, Wes James > wrote: > > Why are you trying to monitor with B. Why not just do: > > test() -> > x(), > do_something(), > y(), > z(). > > -wes > > > > On Thu, Oct 10, 2013 at 2:02 AM, Tyron Zerafa > > wrote: > > Hi, > I would like to monitor a process and suspend the execution > of certain functions to perform some other computation before. > For instance consider a process A which executing the following > simple function. > > test() -> > x(), > y(), > z(). > > I would like to initiate a process, B, that monitors the > execution of A. > I want B to: > 1) stop A before function y is executed > 2) execute some logic > 3) resumes the execution of A (by executing Y and Z) > > So far, I have been following this post > > and managed to determine when the y() function call was being > done, but cannot suspend its execution. Any ideas how I can > achieve this? > > Thanks > Tyron > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -- > Best Regards, > Tyron Zerafa > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From carlsson.richard@REDACTED Fri Oct 11 13:09:48 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 11 Oct 2013 13:09:48 +0200 Subject: [erlang-questions] Running edoc:application( ) on Windows 7, but it's not finding any modules In-Reply-To: References: Message-ID: <5257DC7C.5010609@gmail.com> On 2013-10-11 04:34 , John R. Ashmun wrote: > Hi. > I have a new application, MIX, the directories of which are organized as > recommended in Erlang And OTP In Action, e.g., given that my Erlang-y > home directory is > c:\Program Files\erl5.9\usr\john > the application's top level is "MIX" in my home directory, and in it are > doc > ebin > include > priv > src > There are two modules in src (and the corresponding .beam files in ebin, > along with MIX.app). There is also an overview.edoc file in doc. > I was hoping that, from a command prompt with MIX as its current > directory, that running > werl -pa ebin > and using > edoc:application( 'MIX', ".", [] ). > in the shell would find these modules (which are named 'MIX' and 'M') > and generate some documentation, but this doesn't succeed, although a > nice, rather empty Overview is generated. When you give the path as "-pa ebin", OTP won't realize that the path "ebin" has anything to do with the application 'MIX', so it won't look there. (Btw., it's probably a bad idea in the long run to use uppercase characters for an application name.) In a proper release installation, you'd have added the path in some other way, giving a longer path ".../MIX/ebin" or using the ERL_LIBS environment variable to let OTP find that path for itself. But when testing from the command line like this, you can say "-pa ../MIX/ebin" so that the path contains the application name. Also see section 4.4 in the book. /Richard From ivan@REDACTED Fri Oct 11 14:36:55 2013 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 11 Oct 2013 13:36:55 +0100 Subject: [erlang-questions] Misbehaving ets table in a gen_fsm Message-ID: <5257F0E7.8060006@llaisdy.com> Dear All I am maintaining some code the original author of which has long gone. A gen_fsm has a state variable which is a key/value structure with integer keys. I might use a dict for this, or an array; the author uses an ets table. From some error reports, it looks like this ets table occasionally "mislays" its keys. Perhaps empties or renews itself silently. Finally, in the event of a crash/restart, the data in this ets variable should be preserved and passed on the new gen_fsm process. However, the gen_fsm module has nothing special to handle this in its terminate/3, and init just creates a new table. This is all a bit mysterious so I'm going to write a gen_fsm that has nothing but the above, try and replicate the "mislaying" and generally get it behaving properly. I have three questions: 1. I can't think of any good reason to use an ets table over a dict or an array, other than sharing the data structure with other processes, which isn't done. There are several inconclusive debates on the web about which is fastest. Is there a reason I'm missing for why an ets table might be most appropriate? 2. Under what circumstances if any can an ets table mislay keys? At some point the table stops recognising keys it should know about. There are no other errors in the system. 3. Persisting data across crash & restart I might store the data in the fsm's terminate/3 (if it was a non-normal termination), and check for the stored data in the fsm's init/1. Is that a common approach? has any approach co-allesced into a "pattern" or are types of storage, kinds of data, etc too variable? Might keeping the data in an ets table the whole time remove the need for this step? With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From dmkolesnikov@REDACTED Fri Oct 11 14:52:07 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 11 Oct 2013 15:52:07 +0300 Subject: [erlang-questions] Misbehaving ets table in a gen_fsm In-Reply-To: <5257F0E7.8060006@llaisdy.com> References: <5257F0E7.8060006@llaisdy.com> Message-ID: <5745FEAE-221D-427A-91DA-D951138C2E64@gmail.com> Hello, I think you problems is that ets "owner" process dies and table is released? This is most probably if tables is created within gen_fsm process. 1. ETS one of the performant way to share data among multiple processes? 2. Most probably if the table was destroyed. 3. I think terminate is appropriate approach to "checkpoint" state at "normal" termination. However, if would not guarantee that internal process state is serialised. I would use "checkpoint" by timer or write-through approach. ETS would not preserve data if node crashes therefore "persistency" might require use of amnesia or other storage. From my perspective, ETS is not good approach to "preserve" data in-between of process crash. - Dmitry On Oct 11, 2013, at 3:36 PM, Ivan Uemlianin wrote: > Dear All > > I am maintaining some code the original author of which has long gone. A gen_fsm has a state variable which is a key/value structure with integer keys. I might use a dict for this, or an array; the author uses an ets table. > > From some error reports, it looks like this ets table occasionally "mislays" its keys. Perhaps empties or renews itself silently. > > Finally, in the event of a crash/restart, the data in this ets variable should be preserved and passed on the new gen_fsm process. However, the gen_fsm module has nothing special to handle this in its terminate/3, and init just creates a new table. > > This is all a bit mysterious so I'm going to write a gen_fsm that has nothing but the above, try and replicate the "mislaying" and generally get it behaving properly. > > I have three questions: > > 1. I can't think of any good reason to use an ets table over a dict or an array, other than sharing the data structure with other processes, which isn't done. There are several inconclusive debates on the web about which is fastest. Is there a reason I'm missing for why an ets table might be most appropriate? > > 2. Under what circumstances if any can an ets table mislay keys? At some point the table stops recognising keys it should know about. There are no other errors in the system. > > 3. Persisting data across crash & restart I might store the data in the fsm's terminate/3 (if it was a non-normal termination), and check for the stored data in the fsm's init/1. Is that a common approach? has any approach co-allesced into a "pattern" or are types of storage, kinds of data, etc too variable? Might keeping the data in an ets table the whole time remove the need for this step? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dangud@REDACTED Fri Oct 11 14:53:08 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 11 Oct 2013 14:53:08 +0200 Subject: [erlang-questions] Misbehaving ets table in a gen_fsm In-Reply-To: <5745FEAE-221D-427A-91DA-D951138C2E64@gmail.com> References: <5257F0E7.8060006@llaisdy.com> <5745FEAE-221D-427A-91DA-D951138C2E64@gmail.com> Message-ID: By using ets tables you avoid garbage collection, but instead you copy the data to/from heap whenever you read or write it. So for large datasets you may want to use ets tables to avoid long garbage collection times. On Fri, Oct 11, 2013 at 2:52 PM, Dmitry Kolesnikov wrote: > Hello, > > I think you problems is that ets "owner" process dies and table is > released? This is most probably if tables is created within gen_fsm process. > > 1. ETS one of the performant way to share data among multiple processes? > > 2. Most probably if the table was destroyed. > > 3. I think terminate is appropriate approach to "checkpoint" state at > "normal" termination. However, if would not guarantee that internal process > state is serialised. I would use "checkpoint" by timer or write-through > approach. ETS would not preserve data if node crashes therefore > "persistency" might require use of amnesia or other storage. From my > perspective, ETS is not good approach to "preserve" data in-between of > process crash. > > - Dmitry > > On Oct 11, 2013, at 3:36 PM, Ivan Uemlianin wrote: > > > Dear All > > > > I am maintaining some code the original author of which has long gone. A > gen_fsm has a state variable which is a key/value structure with integer > keys. I might use a dict for this, or an array; the author uses an ets > table. > > > > From some error reports, it looks like this ets table occasionally > "mislays" its keys. Perhaps empties or renews itself silently. > > > > Finally, in the event of a crash/restart, the data in this ets variable > should be preserved and passed on the new gen_fsm process. However, the > gen_fsm module has nothing special to handle this in its terminate/3, and > init just creates a new table. > > > > This is all a bit mysterious so I'm going to write a gen_fsm that has > nothing but the above, try and replicate the "mislaying" and generally get > it behaving properly. > > > > I have three questions: > > > > 1. I can't think of any good reason to use an ets table over a dict or > an array, other than sharing the data structure with other processes, which > isn't done. There are several inconclusive debates on the web about which > is fastest. Is there a reason I'm missing for why an ets table might be > most appropriate? > > > > 2. Under what circumstances if any can an ets table mislay keys? At > some point the table stops recognising keys it should know about. There > are no other errors in the system. > > > > 3. Persisting data across crash & restart I might store the data in the > fsm's terminate/3 (if it was a non-normal termination), and check for the > stored data in the fsm's init/1. Is that a common approach? has any > approach co-allesced into a "pattern" or are types of storage, kinds of > data, etc too variable? Might keeping the data in an ets table the whole > time remove the need for this step? > > > > With thanks and best wishes > > > > Ivan > > > > > > -- > > ============================================================ > > Ivan A. Uemlianin PhD > > Llaisdy > > Speech Technology Research and Development > > > > ivan@REDACTED > > www.llaisdy.com > > llaisdy.wordpress.com > > github.com/llaisdy > > www.linkedin.com/in/ivanuemlianin > > > > festina lente > > ============================================================ > > _______________________________________________ > > 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 dmkolesnikov@REDACTED Fri Oct 11 15:02:23 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 11 Oct 2013 16:02:23 +0300 Subject: [erlang-questions] Misbehaving ets table in a gen_fsm In-Reply-To: References: <5257F0E7.8060006@llaisdy.com> <5745FEAE-221D-427A-91DA-D951138C2E64@gmail.com> Message-ID: I think it is fare to mention that ets benefits on garbage collection to compare with dicts, lists, etc. It would not improve garbage collection of objects by itself. - Dmitry On Oct 11, 2013, at 3:53 PM, Dan Gudmundsson wrote: > By using ets tables you avoid garbage collection, but instead you copy the data to/from heap > whenever you read or write it. > > So for large datasets you may want to use ets tables to avoid long garbage collection times. > > > On Fri, Oct 11, 2013 at 2:52 PM, Dmitry Kolesnikov wrote: > Hello, > > I think you problems is that ets "owner" process dies and table is released? This is most probably if tables is created within gen_fsm process. > > 1. ETS one of the performant way to share data among multiple processes? > > 2. Most probably if the table was destroyed. > > 3. I think terminate is appropriate approach to "checkpoint" state at "normal" termination. However, if would not guarantee that internal process state is serialised. I would use "checkpoint" by timer or write-through approach. ETS would not preserve data if node crashes therefore "persistency" might require use of amnesia or other storage. From my perspective, ETS is not good approach to "preserve" data in-between of process crash. > > - Dmitry > > On Oct 11, 2013, at 3:36 PM, Ivan Uemlianin wrote: > > > Dear All > > > > I am maintaining some code the original author of which has long gone. A gen_fsm has a state variable which is a key/value structure with integer keys. I might use a dict for this, or an array; the author uses an ets table. > > > > From some error reports, it looks like this ets table occasionally "mislays" its keys. Perhaps empties or renews itself silently. > > > > Finally, in the event of a crash/restart, the data in this ets variable should be preserved and passed on the new gen_fsm process. However, the gen_fsm module has nothing special to handle this in its terminate/3, and init just creates a new table. > > > > This is all a bit mysterious so I'm going to write a gen_fsm that has nothing but the above, try and replicate the "mislaying" and generally get it behaving properly. > > > > I have three questions: > > > > 1. I can't think of any good reason to use an ets table over a dict or an array, other than sharing the data structure with other processes, which isn't done. There are several inconclusive debates on the web about which is fastest. Is there a reason I'm missing for why an ets table might be most appropriate? > > > > 2. Under what circumstances if any can an ets table mislay keys? At some point the table stops recognising keys it should know about. There are no other errors in the system. > > > > 3. Persisting data across crash & restart I might store the data in the fsm's terminate/3 (if it was a non-normal termination), and check for the stored data in the fsm's init/1. Is that a common approach? has any approach co-allesced into a "pattern" or are types of storage, kinds of data, etc too variable? Might keeping the data in an ets table the whole time remove the need for this step? > > > > With thanks and best wishes > > > > Ivan > > > > > > -- > > ============================================================ > > Ivan A. Uemlianin PhD > > Llaisdy > > Speech Technology Research and Development > > > > ivan@REDACTED > > www.llaisdy.com > > llaisdy.wordpress.com > > github.com/llaisdy > > www.linkedin.com/in/ivanuemlianin > > > > festina lente > > ============================================================ > > _______________________________________________ > > 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 daniel.goertzen@REDACTED Fri Oct 11 22:49:32 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 11 Oct 2013 15:49:32 -0500 Subject: [erlang-questions] pseudoterminal port process Message-ID: I have an application where I want to run an Erlang SSH server for some highly customized authentication, and then just plumb the i/o to a C++ ncurses port program. The problem I have is that the C++ program expects to run under a terminal, and open_port/2 appears to have no pseudoterminal support. Before I run off and start writing a pseudoterminal wrapper port, is anyone aware of an existing wrapper or some other solution for my problem? Thanks, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Sat Oct 12 02:23:48 2013 From: tony@REDACTED (Tony Rogvall) Date: Sat, 12 Oct 2013 02:23:48 +0200 Subject: [erlang-questions] pseudoterminal port process In-Reply-To: References: Message-ID: <432E3106-89CD-498A-82A1-795F60EBCE5A@rogvall.se> Not exactly sure what you want to do but ... have a look at https://github.com/tonyrog/uart, it has got some support for pseduo terminals, use "//pty" as the device name in uart:open, and then get the name of the selected slave device by calling uart:getopts(Uart, [device]) There is an option {ptypkt, boolean()} that can be used to turn on pty packet mode (TIOCPKT) this is handy for pseudo terminal flow control handling. Because of a little bug, this option can not be given when opening the device but must be set with uart:setopts (there is a fix on its way) /Tony On 11 okt 2013, at 22:49, Daniel Goertzen wrote: > I have an application where I want to run an Erlang SSH server for some highly customized authentication, and then just plumb the i/o to a C++ ncurses port program. The problem I have is that the C++ program expects to run under a terminal, and open_port/2 appears to have no pseudoterminal support. Before I run off and start writing a pseudoterminal wrapper port, is anyone aware of an existing wrapper or some other solution for my problem? > > Thanks, > Dan. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Oct 12 14:05:05 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 12 Oct 2013 14:05:05 +0200 Subject: [erlang-questions] pseudoterminal port process In-Reply-To: <432E3106-89CD-498A-82A1-795F60EBCE5A@rogvall.se> References: <432E3106-89CD-498A-82A1-795F60EBCE5A@rogvall.se> Message-ID: <895ACC04-AAA9-4706-AA05-2C0FE66C9079@gmail.com> Have you ever thought about making your uart:uart() type a #file_descriptor{} as defined in file.hrl? That would allow users to call file functions on a uart handle: https://github.com/erlang/otp/blob/maint/lib/kernel/src/file.erl#L492-493 Regards, Le 12 oct. 2013 ? 02:23, Tony Rogvall a ?crit : > Not exactly sure what you want to do but ... > have a look at https://github.com/tonyrog/uart, it has got some support for pseduo terminals, > use "//pty" as the device name in uart:open, and then get the name of the selected slave > device by calling uart:getopts(Uart, [device]) > > There is an option {ptypkt, boolean()} that can be used to turn on pty packet mode (TIOCPKT) > this is handy for pseudo terminal flow control handling. Because of a little bug, this option > can not be given when opening the device but must be set with uart:setopts (there is a fix on its way) > > /Tony From per@REDACTED Sat Oct 12 14:28:59 2013 From: per@REDACTED (Per Hedeland) Date: Sat, 12 Oct 2013 14:28:59 +0200 (CEST) Subject: [erlang-questions] pseudoterminal port process In-Reply-To: Message-ID: <201310121228.r9CCSxlA051578@pluto.hedeland.org> Daniel Goertzen wrote: > > Before I run off and start writing a pseudoterminal wrapper port, >is anyone aware of an existing wrapper or some other solution for my >problem? http://erlang.org/pipermail/erlang-questions/2013-January/072069.html --Per Hedeland From ok@REDACTED Sun Oct 13 23:56:45 2013 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 14 Oct 2013 10:56:45 +1300 Subject: [erlang-questions] Intrusive function intercept In-Reply-To: References: Message-ID: <4422B837-8146-464C-8412-551EFA57844B@cs.otago.ac.nz> On 11/10/2013, at 10:19 PM, Tyron Zerafa wrote: > First - I do not want to clutter my code with do_something(); I need this perform this call multiple times at different places. > Second - do_something() performs some access control logic, test() is any other function accessing resources. Ideally, developers writing test() functions wouldn't have to worry about access control (this should be hidden). This sounds like aspect-oriented programming, and as such suffers from the rather severe problem of aspect-oriented programming, which is that what you see is not what runs. How can you have any confidence in your code if it might be taken over and do who knows what? Sounds like a case for parse_transform, anyway. From olivier.boudeville@REDACTED Mon Oct 14 11:04:29 2013 From: olivier.boudeville@REDACTED (Olivier BOUDEVILLE) Date: Mon, 14 Oct 2013 11:04:29 +0200 Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: <1381472357.39305.YahooMailNeo@web140105.mail.bf1.yahoo.com> References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> <1381471739.99542.YahooMailNeo@web140101.mail.bf1.yahoo.com> <1381472357.39305.YahooMailNeo@web140105.mail.bf1.yahoo.com> Message-ID: Hello Thomas, Thanks for these pointers. I wasn't aware that higer-order removal could be so fruitful. Would the code of "OM" be publicly available/usable, for inspiration? Best regards, Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 thomasl_erlang@REDACTED 11/10/2013 08:19 Veuillez r?pondre ? thomasl_erlang@REDACTED A olivier.boudeville@REDACTED, tony@REDACTED cc erlang-questions@REDACTED Objet Re: [erlang-questions] "Fat" BEAMs? I should also add that Frej Drejhammar's work on a tracing JIT emulator would enable cross-module inlining etc in a somewhat different context, so it will be quite interesting to see what comes from that. I've only seen a couple of conference presentations yet, looking forward to more. Best, Thomas On Friday, October 11, 2013 8:09 AM, Thomas Lindgren wrote: Hi Olivier, Regarding cross-module optimization and inlining, have a look at these: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.4909 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.6496 Appendix A of the second paper made me realize how much work is going on inside mnesia. For one benchmark, that algorithm decided to inline mnesia:dirty_write/2 something like 10 levels deep through 8 modules, resulting in a 1000-line function. The whole topic needs more work though. Best, Thomas On Thursday, October 10, 2013 1:23 PM, Olivier BOUDEVILLE wrote: Indeed! Additionally, it is quite recent. It could be interesting to measure the speed-up that can actually be obtained, possibly in various settings (native or not, with the various compilers, etc.); maybe this could also allow to have Erlang shine a bit more in some benchmarks! Thanks for the pointer (will definitively try it), Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 tony@REDACTED 10/10/2013 12:34 A olivier.boudeville@REDACTED cc erlang-questions@REDACTED Objet Re: [erlang-questions] "Fat" BEAMs? Maybe give https://github.com/tonyrog/inline a try? /Tony On 10 okt 2013, at 11:56, Olivier BOUDEVILLE wrote: Hi, Let's suppose that, thanks to a parse-transform, we fetched recursively from other modules most if not all code explicitly callable from a given module, so that the full code (ultimately calling only basic language constructs and BIFs) ends up in a single (presumably big, unfolded, possibly inlined) AST. Then, in the prospect of native compilation (HiPe, possibly others like ErLLVM), I imagine that not only we should get rid of the overhead of inter-module calls, but we would also give to the compiler the best full view on which it could operate and generate the best code it could manage? Has this approach already been attempted? Would it have some potential interest? Thanks in advance for any hint, Best regards, Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. _______________________________________________ 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 Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Oct 14 14:03:51 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 14 Oct 2013 05:03:51 -0700 (PDT) Subject: [erlang-questions] "Fat" BEAMs? In-Reply-To: References: <9EFE97D2-16E5-4CDB-B82C-4C94A93DDB7B@rogvall.se> <1381471739.99542.YahooMailNeo@web140101.mail.bf1.yahoo.com> <1381472357.39305.YahooMailNeo@web140105.mail.bf1.yahoo.com> Message-ID: <1381752231.4309.YahooMailNeo@web140101.mail.bf1.yahoo.com> Hi Olivier, Sorry, the code is not public at this time. But it's basically structured around doing many different passes over functions, modules, etc., using erlang syntax trees and profile annotations to guide what to do. Some graph algorithms, some heuristics, a lot of syntax tree passes ...? Regarding your second observation: As I understand it, the beam compiler nowadays does the equivalent of the higher-order removal I looked at in the first paper (that is, it optimizes/specializes the most common lists functions). It might be interesting to go further in this direction (though doing so is substantially more ambitious). In particular, I'm thinking of the Haskell work on fusing higher order functions, which has yielded some very interesting results: http://www.reddit.com/r/haskell/comments/1br0ls/haskell_beats_c_using_generalised_stream_fusion/ Best, Thomas On Monday, October 14, 2013 11:04 AM, Olivier BOUDEVILLE wrote: Hello Thomas, > >Thanks for these pointers. I wasn't aware that higer-order removal could be so fruitful. Would the code of "OM" be publicly available/usable, for inspiration? > >Best regards, > >Olivier. >--------------------------- >Olivier Boudeville > >EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 > > > >thomasl_erlang@REDACTED >11/10/2013 08:19 >Veuillez r?pondre ? >thomasl_erlang@REDACTED > A olivier.boudeville@REDACTED, tony@REDACTED >cc erlang-questions@REDACTED >Objet Re: [erlang-questions] "Fat" BEAMs? > > > > >I should also add that Frej Drejhammar's work on a tracing JIT emulator would enable cross-module inlining etc in a somewhat different context, so it will be quite interesting to see what comes from that. I've only seen a couple of conference presentations yet, looking forward to more. > >Best, >Thomas > > >On Friday, October 11, 2013 8:09 AM, Thomas Lindgren wrote: >Hi Olivier, > >Regarding cross-module optimization and inlining, have a look at these: > >http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.4909 >http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.6496 > >Appendix A of the second paper made me realize how much work is going on inside mnesia. For one benchmark, that algorithm decided to inline mnesia:dirty_write/2 something like 10 levels deep through 8 modules, resulting in a 1000-line function. The whole topic needs more work though. > >Best, >Thomas > > >On Thursday, October 10, 2013 1:23 PM, Olivier BOUDEVILLE wrote: >Indeed! Additionally, it is quite recent. > >It could be interesting to measure the speed-up that can actually be obtained, possibly in various settings (native or not, with the various compilers, etc.); maybe this could also allow to have Erlang shine a bit more in some benchmarks! > >Thanks for the pointer (will definitively try it), > >Olivier. >--------------------------- >Olivier Boudeville > >EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 > > >tony@REDACTED >10/10/2013 12:34 A olivier.boudeville@REDACTED >cc erlang-questions@REDACTED >Objet Re: [erlang-questions] "Fat" BEAMs? > > > > > > >Maybe give https://github.com/tonyrog/inlinea try? > >/Tony > >On 10 okt 2013, at 11:56, Olivier BOUDEVILLE wrote: > >Hi, > >Let's suppose that, thanks to a parse-transform, we fetched recursively from other modules most if not all code explicitly callable from a given module, so that the full code (ultimately calling only basic language constructs and BIFs) ends up in a single (presumably big, unfolded, possibly inlined) AST. > >Then, in ?the prospect of native compilation (HiPe, possibly others like ErLLVM), I imagine that not only we should get rid of the overhead of inter-module calls, but we would also give to the compiler the best full view on which it could operate and generate the best code it could manage? > >Has this approach already been attempted? Would it have some potential interest? > >Thanks in advance for any hint, >Best regards, > >Olivier. >--------------------------- >Olivier Boudeville > >EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France >D?partement SINETICS, groupe ASICS (I2A), bureau B-226 >Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 > >Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. >Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. >Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. >____________________________________________________ >This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. >If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. >E-mail communication cannot be guaranteed to be timely secure, error or virus-free. >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > >"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" > > > > > >Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. >Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. >Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. >____________________________________________________ >This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. >If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. >E-mail communication cannot be guaranteed to be timely secure, error or virus-free. > >_______________________________________________ >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 > > > > >Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. >Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. >Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. >____________________________________________________ >This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. >If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. >E-mail communication cannot be guaranteed to be timely secure, error or virus-free. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Mon Oct 14 15:03:02 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Mon, 14 Oct 2013 15:03:02 +0200 Subject: [erlang-questions] Running edoc:application( ) on Windows 7, but it's not finding any modules In-Reply-To: <5257DC7C.5010609@gmail.com> References: <5257DC7C.5010609@gmail.com> Message-ID: <525BEB86.5020704@gmail.com> It turned out this wasn't due to the search path, but that edoc actively ignores source files whose name starts with an uppercase character. Added it to my list of known bugs. /Richard On 2013-10-11 13:09 , Richard Carlsson wrote: > On 2013-10-11 04:34 , John R. Ashmun wrote: >> Hi. >> I have a new application, MIX, the directories of which are organized as >> recommended in Erlang And OTP In Action, e.g., given that my Erlang-y >> home directory is >> c:\Program Files\erl5.9\usr\john >> the application's top level is "MIX" in my home directory, and in it are >> doc >> ebin >> include >> priv >> src >> There are two modules in src (and the corresponding .beam files in ebin, >> along with MIX.app). There is also an overview.edoc file in doc. >> I was hoping that, from a command prompt with MIX as its current >> directory, that running >> werl -pa ebin >> and using >> edoc:application( 'MIX', ".", [] ). >> in the shell would find these modules (which are named 'MIX' and 'M') >> and generate some documentation, but this doesn't succeed, although a >> nice, rather empty Overview is generated. > > When you give the path as "-pa ebin", OTP won't realize that the path > "ebin" has anything to do with the application 'MIX', so it won't look > there. (Btw., it's probably a bad idea in the long run to use uppercase > characters for an application name.) > > In a proper release installation, you'd have added the path in some > other way, giving a longer path ".../MIX/ebin" or using the ERL_LIBS > environment variable to let OTP find that path for itself. But when > testing from the command line like this, you can say "-pa ../MIX/ebin" > so that the path contains the application name. > > Also see section 4.4 in the book. > > /Richard > From watson.timothy@REDACTED Mon Oct 14 17:43:30 2013 From: watson.timothy@REDACTED (QDev) Date: Mon, 14 Oct 2013 16:43:30 +0100 Subject: [erlang-questions] A (hopefully simple) diameter relay question Message-ID: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> Hi folks, Hopefully I'm being a bit dense and missing some obvious configuration here, but how do I get the OTP application to relay diameter messages to another (externally hosted) diameter server? I start my service with {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections, false} and {use_shared_peers, true}, and then start a listener and a relay to the upstream using the example peer module: peer:connect(?MODULE, {tcp, loopback, 13868}), peer:listen(?MODULE, tcp), However whilst my callback module's handle_request gets called fine, when it returns {relay, [{extra, [relayed]}]}, in the corresponding pick_peer/5 callback there are no remote (or local) peers to select from! Do I need to add additional service configuration in order to relay to another diameter server? The server I am trying to "forward" traffic to is *not* an Erlang/OTP server btw, but some other diameter server (or as it happens in this particular case, a diameter test bed server running on seagull). Cheers, Tim From ulf@REDACTED Mon Oct 14 20:49:09 2013 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 14 Oct 2013 20:49:09 +0200 Subject: [erlang-questions] ANN: locks (beta) - distributed lock manager and leader election In-Reply-To: References: <5B8A53C7-2ECF-4D6D-87A1-25E0CE01B12A@feuerlabs.com> <58DE6BA8-6418-4CA9-95DD-683B47E62F32@feuerlabs.com> <7636F9A1-DF58-41FB-93C0-647253570288@erlang.geek.nz> Message-ID: <34B3C627-71F8-4098-A9CB-02745A77B804@feuerlabs.com> Much better now. I have also ported gproc onto locks_leader. The test suite passes, but I haven't tested much beyond that. https://github.com/uwiger/gproc/tree/uw-locks_leader Note that it's on a separate branch. The official version of gproc still uses gen_leader. If you try it out, please let me know how it goes. Note that you have to start the 'locks' application before starting gproc. BR, Ulf W PS Quite a few subtle details had to be revisited in order to get gproc to work. Most of them had to do with gracefully dealing with split-brain, which was really where most of my testing was focused. On 10 Oct 2013, at 22:00, Ulf Wiger wrote: > > I should mention that the configuration of the locks_leader that I've played with so far is where each candidate is anonymous. Naturally, since I hadn't tested the config where there's one registered candidate on each node, that doesn't work yet. Minor bugs that will be fixed soon. > > BR, > Ulf > > On 10 Oct 2013, at 21:57, Ulf Wiger wrote: > >> >> Hi Geoff, >> >> For the time being, I included Thomas Arts's old description of the algorithm in the README.md (the "Verification" chapter). >> >> That description deals with the locking algorith. The locks_leader behavior simply has all candidates trying to claim a specific lock on every visible node (it would be possible to add an option to restrict the list of candidate nodes). Since the locks_agent will tell its client (a candidate) which other agents & clients are vying for the lock, all candidates can be derived from the lock queue. And since the algorithm will resolve deadlocks through 'lock surrender', one agent will always end up holding all locks*, and thus becomes the leader. >> >> Workers simply monitor the lock, which means they also get the lock updates. Once they get an update, they find any new candidate and send it a message, introducing themselves as workers. >> >> BR, >> Ulf >> >> * It's essentially the same lock on all nodes, but each lock+node instance counts as one lock. This is also why a deadlock situation can occur. >> >> On 10 Oct 2013, at 21:48, Geoff Cant wrote: >> >>> Hi Ulf, do you have a synopsis of the protocol/distributed algorithm the locks_agent run? >>> >>> I had a lot of trouble trying to figure out which protocol/algorithm the gen_leader variants were using the last time I looked at them. Having a description of which algorithm they were implementing (say 'asynchronous bully leader election') and the modifications they made (protocol messages to change the candidate set) would be a significant help to understanding the codebase. >>> >>> -Geoff >>> >>> On 2013-10-09, at 12:41 , Ulf Wiger wrote: >>> >>>> >>>> Right after I sent this, of course I found some issues with the locks_leader and recovery from netsplits - It did it, but it wasn't exactly elegant. Did I mention it was a Beta release?? >>>> >>>> Now it's a lot better, at least in my tests. >>>> >>>> There is now also some documentation of the locks_leader callback under >>>> https://github.com/uwiger/locks/blob/master/examples/doc/test_cb.md >>>> >>>> and the gdict example actually merges the dictionaries after netsplit, albeit in a very non-optimal way. >>>> >>>> >>>> The real nerds may take a look at the locks_watcher code, >>>> >>>> https://github.com/uwiger/locks/blob/master/src/locks_watcher.erl#L12 >>>> >>>> which expands a pseudo-call in the locks_agent into a remote spawn of an interpreted >>>> function, which watches for the locks_server to come up on another node. >>>> >>>> What I think is a bit cool is that the interpreted code is actually implemented as regular >>>> code in this module (lines 22-65). The parse_transform lifts and abstracts the code into >>>> something that becomes interpreted at runtime. >>>> >>>> The end result is that locks_agents react immediately to a locks_server starting on >>>> another node - no polling required. >>>> >>>> BR, >>>> Ulf W >>> >>> >>> >>> >>> >> >> 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 > > 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 Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From maruthavanan_s@REDACTED Tue Oct 15 09:27:15 2013 From: maruthavanan_s@REDACTED (Maruthavanan Subbarayan) Date: Tue, 15 Oct 2013 03:27:15 -0400 Subject: [erlang-questions] Crash during compilation Message-ID: Hi, I am receiving and crash dump during compilation of my code, stating could not allocate memory and takes a lot time. I am able to compile other bigger modules in same environment. I passed and "-v" to put verbose of "erlc" but I could not see any output. Slogan: eheap_alloc: Cannot allocate 1098556536 bytes of memory (of type "heap").System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] I tried 'rebar" as well as "erlc" how can I get more information? I am wondering what area of my code causes heap to grow during compilation? Any ideas? One more interesting fact is, one of the modules which was not changed is also facing this problem suddenly. I also tried copying the folder to Erlang-R14B04, and this also had same problem now. How should I proceed further? Thanks,Marutha -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 15 10:25:02 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Oct 2013 10:25:02 +0200 Subject: [erlang-questions] Crash during compilation In-Reply-To: References: Message-ID: <759CF9F8-E280-4DB9-888F-EC66A66BA45B@gmail.com> Hello, Is your module quite large and uses a lot of binary patterns? Try erlc +time. -- Anthony Ramine Le 15 oct. 2013 ? 09:27, Maruthavanan Subbarayan a ?crit : > Hi, > > I am receiving and crash dump during compilation of my code, stating could not allocate memory and takes a lot time. I am able to compile other bigger modules in same environment. I passed and "-v" to put verbose of "erlc" but I could not see any output. > > Slogan: eheap_alloc: Cannot allocate 1098556536 bytes of memory (of type "heap"). > System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] > > I tried 'rebar" as well as "erlc" how can I get more information? I am wondering what area of my code causes heap to grow during compilation? Any ideas? > > One more interesting fact is, one of the modules which was not changed is also facing this problem suddenly. I also tried copying the folder to Erlang-R14B04, and this also had same problem now. How should I proceed further? > > Thanks, > Marutha > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bourinov@REDACTED Tue Oct 15 10:41:32 2013 From: bourinov@REDACTED (Max Bourinov) Date: Tue, 15 Oct 2013 10:41:32 +0200 Subject: [erlang-questions] Crash during compilation In-Reply-To: References: Message-ID: Hi Marutha, Did you ever succeed with your modules compilation in your current machine (PC)? Best regards, Max Best regards, Max skype: max.bourinov On Tue, Oct 15, 2013 at 9:27 AM, Maruthavanan Subbarayan wrote: > Hi, > > I am receiving and crash dump during compilation of my code, stating could > not allocate memory and takes a lot time. I am able to compile other bigger > modules in same environment. I passed and "-v" to put verbose of "erlc" but > I could not see any output. > > Slogan: eheap_alloc: Cannot allocate 1098556536 bytes of memory (of type > "heap"). > System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] > [async-threads:10] [hipe] [kernel-poll:false] > > I tried 'rebar" as well as "erlc" how can I get more information? I am > wondering what area of my code causes heap to grow during compilation? Any > ideas? > > One more interesting fact is, one of the modules which was not changed is > also facing this problem suddenly. I also tried copying the folder to > Erlang-R14B04, and this also had same problem now. How should I proceed > further? > > Thanks, > Marutha > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From daniel.goertzen@REDACTED Tue Oct 15 16:20:04 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 15 Oct 2013 09:20:04 -0500 Subject: [erlang-questions] pseudoterminal port process In-Reply-To: <201310121228.r9CCSxlA051578@pluto.hedeland.org> References: <201310121228.r9CCSxlA051578@pluto.hedeland.org> Message-ID: Thank you for all the responses. runpty from lux is the direction that I had in mind (https://github.com/hawk/lux/blob/master/c_src/runpty.c) Tony seems curious as to what I'm trying to do, so here it is: We have an embedded system that uses unix accounts, OpenSSH, and an C++ ncurses program for the user interface. For a variety or reasons, we want to get away from unix accounts and go with application-level accounts in much the same way that a typical web app would do. OpenSSH does not appear to support that account model but Erlang SSH can, hence my need for full pseudoterminal support. Thanks again, Dan. On Sat, Oct 12, 2013 at 7:28 AM, Per Hedeland wrote: > Daniel Goertzen wrote: > > > > Before I run off and start writing a pseudoterminal wrapper port, > >is anyone aware of an existing wrapper or some other solution for my > >problem? > > http://erlang.org/pipermail/erlang-questions/2013-January/072069.html > > --Per Hedeland > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Oct 15 17:32:49 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 15 Oct 2013 16:32:49 +0100 Subject: [erlang-questions] A (hopefully simple) diameter relay question In-Reply-To: References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> Message-ID: Putting the list back on cc... So actually, having read through someone else's adventure - http://erlang.org/pipermail/erlang-questions/2013-March/072918.html - I see that if you have multiple 'Auth-Application-Id' entries, you seem to need and {application, Config} tuple for each entry with the relevant dictionary. That's not at all what I want. I wish to 'snoop' on the AVPs and relay all traffic to the real diameter server. I had hoped that by just setting up {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [...., {dictionary, ?DIAMETER_DICT_RELAY}]} that I could avoid all of that. But unless I set the same list of values in 'Auth-Application-Id' on the erlang relay as I do on the server, the capabilities exchange seems to fail. Is it in fact possible to be a transparent relay/proxy in this fashion? I've spent the best part of 24 hours fiddling around with auth-app-ids in the test client / server and that's fair enough - but now the test client and server will happily talk directly to each other, but once the erlang relay gets in the middle it all falls apart. There must be some rules about how to configure a relay agent that I'm missing. Cheers, Tim On 15 Oct 2013, at 10:32, Ferenc Holzhauser wrote: > Hi Tim, > > AFAIK the restrict_connections and use_shared_peers options are internal to the diameter app for the case it is distributed when connections may be handled on different erlang nodes. > > Typically if pick peer doesn't give you anything to pick from (assuming that peers are connected) then the remote end didn't announce support for the app id you're trying to send to (and/or tell that he is a jolly joker relay accepting anything). You being relay is not doing a lot when sending IMO. > What did your seagull announce when connecting? > > BR, > Ferenc > > > > > On 14 October 2013 17:43, QDev wrote: > Hi folks, > > Hopefully I'm being a bit dense and missing some obvious configuration here, but how do I get the OTP application to relay diameter messages to another (externally hosted) diameter server? I start my service with {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections, false} and {use_shared_peers, true}, and then start a listener and a relay to the upstream using the example peer module: > > peer:connect(?MODULE, {tcp, loopback, 13868}), > peer:listen(?MODULE, tcp), > > However whilst my callback module's handle_request gets called fine, when it returns {relay, [{extra, [relayed]}]}, in the corresponding pick_peer/5 callback there are no remote (or local) peers to select from! Do I need to add additional service configuration in order to relay to another diameter server? The server I am trying to "forward" traffic to is *not* an Erlang/OTP server btw, but some other diameter server (or as it happens in this particular case, a diameter test bed server running on seagull). > > Cheers, > Tim > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Oct 15 18:13:51 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 15 Oct 2013 17:13:51 +0100 Subject: [erlang-questions] A (hopefully simple) diameter relay question In-Reply-To: References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> Message-ID: <8EC26317-7574-4438-9090-C4F5B15F8F4A@gmail.com> In fact, according to RFC 3588: Relay and redirect agents MUST advertise the Relay Application Identifier, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange message advertising Relay service MUST assume that the sender supports all current and future applications. So I would've expected just supplying ?DIAMETER_APP_ID_RELAY and ?DIAMETER_DICT_RELAY to be enough. On 15 Oct 2013, at 16:32, Tim Watson wrote: > Putting the list back on cc... > > So actually, having read through someone else's adventure - http://erlang.org/pipermail/erlang-questions/2013-March/072918.html - I see that if you have multiple 'Auth-Application-Id' entries, you seem to need and {application, Config} tuple for each entry with the relevant dictionary. That's not at all what I want. I wish to 'snoop' on the AVPs and relay all traffic to the real diameter server. I had hoped that by just setting up > > {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [...., {dictionary, ?DIAMETER_DICT_RELAY}]} > > that I could avoid all of that. > > But unless I set the same list of values in 'Auth-Application-Id' on the erlang relay as I do on the server, the capabilities exchange seems to fail. Is it in fact possible to be a transparent relay/proxy in this fashion? I've spent the best part of 24 hours fiddling around with auth-app-ids in the test client / server and that's fair enough - but now the test client and server will happily talk directly to each other, but once the erlang relay gets in the middle it all falls apart. There must be some rules about how to configure a relay agent that I'm missing. > > Cheers, > Tim > > On 15 Oct 2013, at 10:32, Ferenc Holzhauser wrote: > >> Hi Tim, >> >> AFAIK the restrict_connections and use_shared_peers options are internal to the diameter app for the case it is distributed when connections may be handled on different erlang nodes. >> >> Typically if pick peer doesn't give you anything to pick from (assuming that peers are connected) then the remote end didn't announce support for the app id you're trying to send to (and/or tell that he is a jolly joker relay accepting anything). You being relay is not doing a lot when sending IMO. >> What did your seagull announce when connecting? >> >> BR, >> Ferenc >> >> >> >> >> On 14 October 2013 17:43, QDev wrote: >> Hi folks, >> >> Hopefully I'm being a bit dense and missing some obvious configuration here, but how do I get the OTP application to relay diameter messages to another (externally hosted) diameter server? I start my service with {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections, false} and {use_shared_peers, true}, and then start a listener and a relay to the upstream using the example peer module: >> >> peer:connect(?MODULE, {tcp, loopback, 13868}), >> peer:listen(?MODULE, tcp), >> >> However whilst my callback module's handle_request gets called fine, when it returns {relay, [{extra, [relayed]}]}, in the corresponding pick_peer/5 callback there are no remote (or local) peers to select from! Do I need to add additional service configuration in order to relay to another diameter server? The server I am trying to "forward" traffic to is *not* an Erlang/OTP server btw, but some other diameter server (or as it happens in this particular case, a diameter test bed server running on seagull). >> >> Cheers, >> Tim >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothma@REDACTED Tue Oct 15 18:34:04 2013 From: jbothma@REDACTED (JD Bothma) Date: Tue, 15 Oct 2013 18:34:04 +0200 Subject: [erlang-questions] Crash during compilation In-Reply-To: References: Message-ID: uninformed debugging ideas: Can you reproduce it with half of the module? Can you then isolate a specific part of the module that ends up taking a lot of memory to compile? Are you including any odd hrl's? JD On 15 October 2013 09:27, Maruthavanan Subbarayan < maruthavanan_s@REDACTED> wrote: > Hi, > > I am receiving and crash dump during compilation of my code, stating could > not allocate memory and takes a lot time. I am able to compile other bigger > modules in same environment. I passed and "-v" to put verbose of "erlc" but > I could not see any output. > > Slogan: eheap_alloc: Cannot allocate 1098556536 bytes of memory (of type > "heap"). > System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] > [async-threads:10] [hipe] [kernel-poll:false] > > I tried 'rebar" as well as "erlc" how can I get more information? I am > wondering what area of my code causes heap to grow during compilation? Any > ideas? > > One more interesting fact is, one of the modules which was not changed is > also facing this problem suddenly. I also tried copying the folder to > Erlang-R14B04, and this also had same problem now. How should I proceed > further? > > Thanks, > Marutha > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 15 18:55:19 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Oct 2013 18:55:19 +0200 Subject: [erlang-questions] Crash during compilation In-Reply-To: References: , <759CF9F8-E280-4DB9-888F-EC66A66BA45B@gmail.com> Message-ID: <9EBA66D6-7EB2-4AD7-B393-C1C419EB2762@gmail.com> Are you sure of that? This should error out with "circular macro 'MACRO'". -- Anthony Ramine Le 15 oct. 2013 ? 10:40, Maruthavanan Subbarayan a ?crit : > Hi, > > I think I did an accidental typo that caused because of copy paste. Took almost 6 hours of mine :) Learnt copy paste bad very bad sometimes :) > > Just to let community know, I was trying to do something like below. > > -define(MACRO, [?MACRO]). > > Thanks, > Marutha > > > Subject: Re: [erlang-questions] Crash during compilation > > From: n.oxyde@REDACTED > > Date: Tue, 15 Oct 2013 10:25:02 +0200 > > CC: erlang-questions@REDACTED > > To: maruthavanan_s@REDACTED > > > > Hello, > > > > Is your module quite large and uses a lot of binary patterns? > > > > Try erlc +time. > > > > -- > > Anthony Ramine > > > > Le 15 oct. 2013 ? 09:27, Maruthavanan Subbarayan a ?crit : > > > > > Hi, > > > > > > I am receiving and crash dump during compilation of my code, stating could not allocate memory and takes a lot time. I am able to compile other bigger modules in same environment. I passed and "-v" to put verbose of "erlc" but I could not see any output. > > > > > > Slogan: eheap_alloc: Cannot allocate 1098556536 bytes of memory (of type "heap"). > > > System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] > > > > > > I tried 'rebar" as well as "erlc" how can I get more information? I am wondering what area of my code causes heap to grow during compilation? Any ideas? > > > > > > One more interesting fact is, one of the modules which was not changed is also facing this problem suddenly. I also tried copying the folder to Erlang-R14B04, and this also had same problem now. How should I proceed further? > > > > > > Thanks, > > > Marutha > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > From n.oxyde@REDACTED Wed Oct 16 11:05:42 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 16 Oct 2013 11:05:42 +0200 Subject: [erlang-questions] Crash during compilation In-Reply-To: References: <759CF9F8-E280-4DB9-888F-EC66A66BA45B@gmail.com> <9EBA66D6-7EB2-4AD7-B393-C1C419EB2762@gmail.com> Message-ID: <3B6E17BB-DDD0-4C10-B0E1-265A002555F4@gmail.com> Please keep the discussion on the list, thank you. -- Anthony Ramine > Le 15 oct. 2013 ? 20:40, Maruthavanan Subbarayan a ?crit : > > HI, > > Since after I removed that the same did not occur, but for sure it occurred when I included that. The circular macro should be defined in a header file. > > One more note it just declaring the macro would not reproduce this, the declared macro should be used somewhere in the code like below. > > t.hrl > ================== > -define(MACRO,[[]++?MACRO]). > > heap_error.erl > =============== > -module(heap_error). > -compile(export_all). > > -include("t.hrl"). > > %-define(MACRO,["test",?MACRO]). > > > function_name()-> > A=?MACRO, > ok. > > > Subject: Re: [erlang-questions] Crash during compilation > > From: n.oxyde@REDACTED > > Date: Tue, 15 Oct 2013 18:55:19 +0200 > > CC: erlang-questions@REDACTED > > To: maruthavanan_s@REDACTED > > > > Are you sure of that? > > > > This should error out with "circular macro 'MACRO'". > > > > -- > > Anthony Ramine > > > > Le 15 oct. 2013 ? 10:40, Maruthavanan Subbarayan a ?crit : > > > > > Hi, > > > > > > I think I did an accidental typo that caused because of copy paste. Took almost 6 hours of mine :) Learnt copy paste bad very bad sometimes :) > > > > > > Just to let community know, I was trying to do something like below. > > > > > > -define(MACRO, [?MACRO]). > > > > > > Thanks, > > > Marutha > > > > > > > Subject: Re: [erlang-questions] Crash during compilation > > > > From: n.oxyde@REDACTED > > > > Date: Tue, 15 Oct 2013 10:25:02 +0200 > > > > CC: erlang-questions@REDACTED > > > > To: maruthavanan_s@REDACTED > > > > > > > > Hello, > > > > > > > > Is your module quite large and uses a lot of binary patterns? > > > > > > > > Try erlc +time. > > > > > > > > -- > > > > Anthony Ramine > > > > > > > > Le 15 oct. 2013 ? 09:27, Maruthavanan Subbarayan a ?crit : > > > > > > > > > Hi, > > > > > > > > > > I am receiving and crash dump during compilation of my code, stating could not allocate memory and takes a lot time. I am able to compile other bigger modules in same environment. I passed and "-v" to put verbose of "erlc" but I could not see any output. > > > > > > > > > > Slogan: eheap_alloc: Cannot allocate 1098556536 bytes of memory (of type "heap"). > > > > > System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] > > > > > > > > > > I tried 'rebar" as well as "erlc" how can I get more information? I am wondering what area of my code causes heap to grow during compilation? Any ideas? > > > > > > > > > > One more interesting fact is, one of the modules which was not changed is also facing this problem suddenly. I also tried copying the folder to Erlang-R14B04, and this also had same problem now. How should I proceed further? > > > > > > > > > > Thanks, > > > > > Marutha > > > > > _______________________________________________ > > > > > erlang-questions mailing list > > > > > erlang-questions@REDACTED > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Wed Oct 16 11:46:07 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 16 Oct 2013 11:46:07 +0200 Subject: [erlang-questions] Crash during compilation In-Reply-To: <3B6E17BB-DDD0-4C10-B0E1-265A002555F4@gmail.com> References: <759CF9F8-E280-4DB9-888F-EC66A66BA45B@gmail.com> <9EBA66D6-7EB2-4AD7-B393-C1C419EB2762@gmail.com> <3B6E17BB-DDD0-4C10-B0E1-265A002555F4@gmail.com> Message-ID: <525E605F.5010104@gmail.com> Confirmed. Seems like the function leave_file/2 in epp.erl propagates the macro definitions from the include file, but not the 'uses' field of the preprocessor state when it leaves the header file. /Richard On 2013-10-16 11:05 , Anthony Ramine wrote: > Please keep the discussion on the list, thank you. > > -- > Anthony Ramine > > Le 15 oct. 2013 ? 20:40, Maruthavanan Subbarayan > > a ?crit : > >> HI, >> >> Since after I removed that the same did not occur, but for sure it >> occurred when I included that. The circular macro should be defined in >> a header file. >> >> One more note it just declaring the macro would not reproduce this, >> the declared macro should be used somewhere in the code like below. >> >> t.hrl >> ================== >> -define(MACRO,[[]++?MACRO]). >> >> heap_error.erl >> =============== >> -module(heap_error). >> -compile(export_all). >> >> -include("t.hrl"). >> >> %-define(MACRO,["test",?MACRO]). >> >> >> function_name()-> >> A=?MACRO, >> ok. >> >> > Subject: Re: [erlang-questions] Crash during compilation >> > From: n.oxyde@REDACTED >> > Date: Tue, 15 Oct 2013 18:55:19 +0200 >> > CC: erlang-questions@REDACTED >> > To: maruthavanan_s@REDACTED >> > >> > Are you sure of that? >> > >> > This should error out with "circular macro 'MACRO'". >> > >> > -- >> > Anthony Ramine >> > >> > Le 15 oct. 2013 ? 10:40, Maruthavanan Subbarayan >> > a ?crit : >> > >> > > Hi, >> > > >> > > I think I did an accidental typo that caused because of copy >> paste. Took almost 6 hours of mine :) Learnt copy paste bad very bad >> sometimes :) >> > > >> > > Just to let community know, I was trying to do something like below. >> > > >> > > -define(MACRO, [?MACRO]). >> > > >> > > Thanks, >> > > Marutha >> > > >> > > > Subject: Re: [erlang-questions] Crash during compilation >> > > > From: n.oxyde@REDACTED >> > > > Date: Tue, 15 Oct 2013 10:25:02 +0200 >> > > > CC: erlang-questions@REDACTED >> > > > To: maruthavanan_s@REDACTED >> > > > >> > > > Hello, >> > > > >> > > > Is your module quite large and uses a lot of binary patterns? >> > > > >> > > > Try erlc +time. >> > > > >> > > > -- >> > > > Anthony Ramine >> > > > >> > > > Le 15 oct. 2013 ? 09:27, Maruthavanan Subbarayan >> > a ?crit : >> > > > >> > > > > Hi, >> > > > > >> > > > > I am receiving and crash dump during compilation of my code, >> stating could not allocate memory and takes a lot time. I am able to >> compile other bigger modules in same environment. I passed and "-v" to >> put verbose of "erlc" but I could not see any output. >> > > > > >> > > > > Slogan: eheap_alloc: Cannot allocate 1098556536 bytes of >> memory (of type "heap"). >> > > > > System version: Erlang R16B02 (erts-5.10.3) [source] [64-bit] >> [async-threads:10] [hipe] [kernel-poll:false] >> > > > > >> > > > > I tried 'rebar" as well as "erlc" how can I get more >> information? I am wondering what area of my code causes heap to grow >> during compilation? Any ideas? >> > > > > >> > > > > One more interesting fact is, one of the modules which was not >> changed is also facing this problem suddenly. I also tried copying the >> folder to Erlang-R14B04, and this also had same problem now. How >> should I proceed further? >> > > > > >> > > > > Thanks, >> > > > > Marutha >> > > > > _______________________________________________ >> > > > > 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 anders.otp@REDACTED Wed Oct 16 12:22:04 2013 From: anders.otp@REDACTED (Anders Svensson) Date: Wed, 16 Oct 2013 12:22:04 +0200 Subject: [erlang-questions] A (hopefully simple) diameter relay question In-Reply-To: References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> Message-ID: Hi Tim. On Tue, Oct 15, 2013 at 5:32 PM, Tim Watson wrote: > Putting the list back on cc... > > So actually, having read through someone else's adventure - > http://erlang.org/pipermail/erlang-questions/2013-March/072918.html - I see > that if you have multiple 'Auth-Application-Id' entries, you seem to need > and {application, Config} tuple for each entry with the relevant dictionary. > That's not at all what I want. I wish to 'snoop' on the AVPs and relay all > traffic to the real diameter server. I had hoped that by just setting up > > {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [...., > {dictionary, ?DIAMETER_DICT_RELAY}]} > > that I could avoid all of that. Yes, this is the right thing to do. > But unless I set the same list of values in 'Auth-Application-Id' on the > erlang relay as I do on the server, the capabilities exchange seems to fail. How do the CER/CEA messages look when it fails? /Anders, Erlang/OTP > Is it in fact possible to be a transparent relay/proxy in this fashion? I've > spent the best part of 24 hours fiddling around with auth-app-ids in the > test client / server and that's fair enough - but now the test client and > server will happily talk directly to each other, but once the erlang relay > gets in the middle it all falls apart. There must be some rules about how to > configure a relay agent that I'm missing. > > Cheers, > Tim > > On 15 Oct 2013, at 10:32, Ferenc Holzhauser wrote: > > Hi Tim, > > AFAIK the restrict_connections and use_shared_peers options are internal to > the diameter app for the case it is distributed when connections may be > handled on different erlang nodes. > > Typically if pick peer doesn't give you anything to pick from (assuming that > peers are connected) then the remote end didn't announce support for the app > id you're trying to send to (and/or tell that he is a jolly joker relay > accepting anything). You being relay is not doing a lot when sending IMO. > What did your seagull announce when connecting? > > BR, > Ferenc > > > > > On 14 October 2013 17:43, QDev wrote: >> >> Hi folks, >> >> Hopefully I'm being a bit dense and missing some obvious configuration >> here, but how do I get the OTP application to relay diameter messages to >> another (externally hosted) diameter server? I start my service with >> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections, >> false} and {use_shared_peers, true}, and then start a listener and a relay >> to the upstream using the example peer module: >> >> peer:connect(?MODULE, {tcp, loopback, 13868}), >> peer:listen(?MODULE, tcp), >> >> However whilst my callback module's handle_request gets called fine, when >> it returns {relay, [{extra, [relayed]}]}, in the corresponding pick_peer/5 >> callback there are no remote (or local) peers to select from! Do I need to >> add additional service configuration in order to relay to another diameter >> server? The server I am trying to "forward" traffic to is *not* an >> Erlang/OTP server btw, but some other diameter server (or as it happens in >> this particular case, a diameter test bed server running on seagull). >> >> Cheers, >> Tim >> _______________________________________________ >> 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 watson.timothy@REDACTED Wed Oct 16 12:39:42 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 16 Oct 2013 11:39:42 +0100 Subject: [erlang-questions] A (hopefully simple) diameter relay question In-Reply-To: References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> Message-ID: Hi Anders, On 16 Oct 2013, at 11:22, Anders Svensson wrote: > On Tue, Oct 15, 2013 at 5:32 PM, Tim Watson wrote: >> I had hoped that by just setting up >> >> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [...., >> {dictionary, ?DIAMETER_DICT_RELAY}]} >> >> that I could avoid all of that. > > Yes, this is the right thing to do. > Ah, good to know. >> But unless I set the same list of values in 'Auth-Application-Id' on the >> erlang relay as I do on the server, the capabilities exchange seems to fail. > > How do the CER/CEA messages look when it fails? > I'm not in front of it right now, but as soon as I am, I'll look through the wireshark traces and post back. Thanks! Tim From max.lapshin@REDACTED Thu Oct 17 11:49:32 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 17 Oct 2013 13:49:32 +0400 Subject: [erlang-questions] memsup errors on Mac OS X 10.8.4 Message-ID: (flussonic@REDACTED)49> 13:02:03.502 emulator Error in process <0.16248.3> on node 'flussonic@REDACTED' with exit value: {{case_clause,{more,"Pages free:~d.",0,[]}},[{memsup,fread_value,2,[{file,"memsup.erl"},{line,760}]},{memsup,get_memory_usage,1,[{file,"memsup.erl"},{line,730}]},{memsup,'-handle_call/3-fun-1-',2,[{file,"memsup.erl"},{line,285}]}]} Looks like something two years ago: http://erlang.org/pipermail/erlang-bugs/2009-October/001559.html Currently my vm_stat shows: $ vm_stat Mach Virtual Memory Statistics: (page size of 4096 bytes) Pages free: 979676. Pages active: 603451. Pages inactive: 74428. Pages speculative: 162379. Pages wired down: 243971. "Translation faults": 244013412. Pages copy-on-write: 15480794. Pages zero filled: 211325884. Pages reactivated: 428830. Pageins: 22645518. Pageouts: 0. Object cache: 14 hits of 372888 lookups (0% hit rate) Can I provide any other information about this failure? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Thu Oct 17 14:06:23 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 17 Oct 2013 08:06:23 -0400 Subject: [erlang-questions] memsup errors on Mac OS X 10.8.4 In-Reply-To: References: Message-ID: On Thu, Oct 17, 2013 at 5:49 AM, Max Lapshin wrote: > (flussonic@REDACTED)49> 13:02:03.502 emulator Error in process > <0.16248.3> on node 'flussonic@REDACTED' with exit value: > {{case_clause,{more,"Pages > free:~d.",0,[]}},[{memsup,fread_value,2,[{file,"memsup.erl"},{line,760}]},{memsup,get_memory_usage,1,[{file,"memsup.erl"},{line,730}]},{memsup,'-handle_call/3-fun-1-',2,[{file,"memsup.erl"},{line,285}]}]} > I saw this a few months ago and had a brief email discussion with Bj?rn-Egil Dahlberg about it. I believe the only way the error happens is if /usr/bin/vm_stat returns an empty string. Feel free to disagree, but our discussion concluded that the error was rare enough that it fell into the "let it crash" category, and since memsup just restarts when that happens, we opted not to patch it. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From 249505968@REDACTED Thu Oct 17 14:07:12 2013 From: 249505968@REDACTED (=?gb18030?B?99L30Q==?=) Date: Thu, 17 Oct 2013 20:07:12 +0800 Subject: [erlang-questions] erlang-questions Digest, Vol 135, Issue 4 In-Reply-To: References: Message-ID: Can erlang read xlsx file (excel file)? ------------------ Original ------------------ From: "erlang-questions-request";; Date: Thu, Oct 17, 2013 06:00 PM To: "erlang-questions"; Subject: erlang-questions Digest, Vol 135, Issue 4 Send erlang-questions mailing list submissions to erlang-questions@REDACTED To subscribe or unsubscribe via the World Wide Web, visit http://erlang.org/mailman/listinfo/erlang-questions or, via email, send a message with subject or body 'help' to erlang-questions-request@REDACTED You can reach the person managing the list at erlang-questions-owner@REDACTED When replying, please edit your Subject line so it is more specific than "Re: Contents of erlang-questions digest..." Today's Topics: 1. Re: A (hopefully simple) diameter relay question (Anders Svensson) 2. Re: A (hopefully simple) diameter relay question (Tim Watson) 3. memsup errors on Mac OS X 10.8.4 (Max Lapshin) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Oct 2013 12:22:04 +0200 From: Anders Svensson To: Tim Watson Cc: "erlang-questions@REDACTED Questions" Subject: Re: [erlang-questions] A (hopefully simple) diameter relay question Message-ID: Content-Type: text/plain; charset=UTF-8 Hi Tim. On Tue, Oct 15, 2013 at 5:32 PM, Tim Watson wrote: > Putting the list back on cc... > > So actually, having read through someone else's adventure - > http://erlang.org/pipermail/erlang-questions/2013-March/072918.html - I see > that if you have multiple 'Auth-Application-Id' entries, you seem to need > and {application, Config} tuple for each entry with the relevant dictionary. > That's not at all what I want. I wish to 'snoop' on the AVPs and relay all > traffic to the real diameter server. I had hoped that by just setting up > > {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [...., > {dictionary, ?DIAMETER_DICT_RELAY}]} > > that I could avoid all of that. Yes, this is the right thing to do. > But unless I set the same list of values in 'Auth-Application-Id' on the > erlang relay as I do on the server, the capabilities exchange seems to fail. How do the CER/CEA messages look when it fails? /Anders, Erlang/OTP > Is it in fact possible to be a transparent relay/proxy in this fashion? I've > spent the best part of 24 hours fiddling around with auth-app-ids in the > test client / server and that's fair enough - but now the test client and > server will happily talk directly to each other, but once the erlang relay > gets in the middle it all falls apart. There must be some rules about how to > configure a relay agent that I'm missing. > > Cheers, > Tim > > On 15 Oct 2013, at 10:32, Ferenc Holzhauser wrote: > > Hi Tim, > > AFAIK the restrict_connections and use_shared_peers options are internal to > the diameter app for the case it is distributed when connections may be > handled on different erlang nodes. > > Typically if pick peer doesn't give you anything to pick from (assuming that > peers are connected) then the remote end didn't announce support for the app > id you're trying to send to (and/or tell that he is a jolly joker relay > accepting anything). You being relay is not doing a lot when sending IMO. > What did your seagull announce when connecting? > > BR, > Ferenc > > > > > On 14 October 2013 17:43, QDev wrote: >> >> Hi folks, >> >> Hopefully I'm being a bit dense and missing some obvious configuration >> here, but how do I get the OTP application to relay diameter messages to >> another (externally hosted) diameter server? I start my service with >> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections, >> false} and {use_shared_peers, true}, and then start a listener and a relay >> to the upstream using the example peer module: >> >> peer:connect(?MODULE, {tcp, loopback, 13868}), >> peer:listen(?MODULE, tcp), >> >> However whilst my callback module's handle_request gets called fine, when >> it returns {relay, [{extra, [relayed]}]}, in the corresponding pick_peer/5 >> callback there are no remote (or local) peers to select from! Do I need to >> add additional service configuration in order to relay to another diameter >> server? The server I am trying to "forward" traffic to is *not* an >> Erlang/OTP server btw, but some other diameter server (or as it happens in >> this particular case, a diameter test bed server running on seagull). >> >> Cheers, >> Tim >> _______________________________________________ >> 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 > ------------------------------ Message: 2 Date: Wed, 16 Oct 2013 11:39:42 +0100 From: Tim Watson To: Anders Svensson Cc: "erlang-questions@REDACTED Questions" Subject: Re: [erlang-questions] A (hopefully simple) diameter relay question Message-ID: Content-Type: text/plain; charset=us-ascii Hi Anders, On 16 Oct 2013, at 11:22, Anders Svensson wrote: > On Tue, Oct 15, 2013 at 5:32 PM, Tim Watson wrote: >> I had hoped that by just setting up >> >> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [...., >> {dictionary, ?DIAMETER_DICT_RELAY}]} >> >> that I could avoid all of that. > > Yes, this is the right thing to do. > Ah, good to know. >> But unless I set the same list of values in 'Auth-Application-Id' on the >> erlang relay as I do on the server, the capabilities exchange seems to fail. > > How do the CER/CEA messages look when it fails? > I'm not in front of it right now, but as soon as I am, I'll look through the wireshark traces and post back. Thanks! Tim ------------------------------ Message: 3 Date: Thu, 17 Oct 2013 13:49:32 +0400 From: Max Lapshin To: Erlang-Questions Questions Subject: [erlang-questions] memsup errors on Mac OS X 10.8.4 Message-ID: Content-Type: text/plain; charset="utf-8" (flussonic@REDACTED)49> 13:02:03.502 emulator Error in process <0.16248.3> on node 'flussonic@REDACTED' with exit value: {{case_clause,{more,"Pages free:~d.",0,[]}},[{memsup,fread_value,2,[{file,"memsup.erl"},{line,760}]},{memsup,get_memory_usage,1,[{file,"memsup.erl"},{line,730}]},{memsup,'-handle_call/3-fun-1-',2,[{file,"memsup.erl"},{line,285}]}]} Looks like something two years ago: http://erlang.org/pipermail/erlang-bugs/2009-October/001559.html Currently my vm_stat shows: $ vm_stat Mach Virtual Memory Statistics: (page size of 4096 bytes) Pages free: 979676. Pages active: 603451. Pages inactive: 74428. Pages speculative: 162379. Pages wired down: 243971. "Translation faults": 244013412. Pages copy-on-write: 15480794. Pages zero filled: 211325884. Pages reactivated: 428830. Pageins: 22645518. Pageouts: 0. Object cache: 14 hits of 372888 lookups (0% hit rate) Can I provide any other information about this failure? -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions End of erlang-questions Digest, Vol 135, Issue 4 ************************************************ . -------------- next part -------------- An HTML attachment was scrubbed... URL: From 249505968@REDACTED Thu Oct 17 14:10:49 2013 From: 249505968@REDACTED (=?gb18030?B?99L30Q==?=) Date: Thu, 17 Oct 2013 20:10:49 +0800 Subject: [erlang-questions] Can erlang read xlsx? Message-ID: Our project have used a lot of xlsx.... So could someone teach me how to read xlsx by erlang... -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Oct 17 14:12:48 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 17 Oct 2013 16:12:48 +0400 Subject: [erlang-questions] memsup errors on Mac OS X 10.8.4 In-Reply-To: References: Message-ID: Ok, got it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourinov@REDACTED Thu Oct 17 14:40:00 2013 From: bourinov@REDACTED (Max Bourinov) Date: Thu, 17 Oct 2013 14:40:00 +0200 Subject: [erlang-questions] Can erlang read xlsx? In-Reply-To: References: Message-ID: I would suggest you to use other libs for that. Say PHP or something similar, and then pass data to Erlang. I don't know your use case, but if somebody from my team would propose reading xlsx from Erlang I would definitely think that it is misuse of Erlang. Best regards, Max skype: max.bourinov On Thu, Oct 17, 2013 at 2:10 PM, ?? <249505968@REDACTED> wrote: > Our project have used a lot of xlsx.... > So could someone teach me how to read xlsx by erlang... > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmercer@REDACTED Thu Oct 17 15:00:24 2013 From: dmercer@REDACTED (David Mercer) Date: Thu, 17 Oct 2013 08:00:24 -0500 Subject: [erlang-questions] Can erlang read xlsx? In-Reply-To: References: Message-ID: <00b601cecb38$d8a23800$89e6a800$@gmail.com> It?s only a misuse because the library hasn?t been written yet. It should be just as doable in Erlang as any other language, using the zip module to open the file and xmerl to interpret it. Cheers, DBM From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Max Bourinov Sent: Thursday, October 17, 2013 07:40 To: ?? Cc: erlang-questions Subject: Re: [erlang-questions] Can erlang read xlsx? I would suggest you to use other libs for that. Say PHP or something similar, and then pass data to Erlang. I don't know your use case, but if somebody from my team would propose reading xlsx from Erlang I would definitely think that it is misuse of Erlang. Best regards, Max skype: max.bourinov On Thu, Oct 17, 2013 at 2:10 PM, ?? <249505968@REDACTED> wrote: Our project have used a lot of xlsx.... So could someone teach me how to read xlsx by erlang... _______________________________________________ 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 Oct 17 15:01:31 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 17 Oct 2013 17:01:31 +0400 Subject: [erlang-questions] Can erlang read xlsx? In-Reply-To: <00b601cecb38$d8a23800$89e6a800$@gmail.com> References: <00b601cecb38$d8a23800$89e6a800$@gmail.com> Message-ID: I'm editing xlsx in erlang. Unzip, re:replace and zip back. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.platt@REDACTED Thu Oct 17 16:02:34 2013 From: pablo.platt@REDACTED (pablo platt) Date: Thu, 17 Oct 2013 17:02:34 +0300 Subject: [erlang-questions] DTLS client/server In-Reply-To: References: <-2812677860635758685@unknownmsgid> Message-ID: Is there a chance for release preview of DTLS before the R17 release on February? Thanks On Thu, Aug 1, 2013 at 1:03 AM, pablo platt wrote: > I see some DTLS files in the source: > https://github.com/erlang/otp/tree/maint/lib/ssl/src > > Is it unusable or just unstable? > > Do you have a rough estimate when we can expect it? > Next minor release? Next major release? > > Thanks > > > On Thu, Aug 1, 2013 at 12:57 AM, Ingela Andin wrote: > >> Hi, OTP is working on that but it is not ready yet. >> Regards Ingela - OTP team Ericsson AB >> >> Skickat fr?n min iPhone >> >> 31 jul 2013 kl. 17:52 skrev pablo platt : >> >> Hi, >> >> Is there a library that implements DTLS client and server in Erlang? >> DTLS is the UDP version of TLS >> Datagram Transport Layer Security >> http://tools.ietf.org/html/rfc4347 >> >> Thanks >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Thu Oct 17 16:23:29 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Thu, 17 Oct 2013 16:23:29 +0200 (CEST) Subject: [erlang-questions] DTLS client/server In-Reply-To: References: <-2812677860635758685@unknownmsgid> Message-ID: <306505251.505514.1382019809812.JavaMail.zimbra@tpip.net> Hi Pablo, I you are desperate to have something working right now, you can always use my prototype from there: https://github.com/RoadRunnr/otp/tree/new_crypto_dtls But be aware that the OTP version will have a different API. My version uses a wrapper module to read DTLS traffic from somewhere and pass it into the SSL library. For udp, lib/ssl/src/ssl_udp.erl already exists and [{versions, ['dtlsv1.2', dtlsv1]}, {cb_info, ssl_udp}] in your ssl options should work. For other transport layers, you have to implement that module yourself. Andreas ----- Original Message ----- > Is there a chance for release preview of DTLS before the R17 release on > February? > > Thanks > > > > On Thu, Aug 1, 2013 at 1:03 AM, pablo platt < pablo.platt@REDACTED > wrote: > > > > I see some DTLS files in the source: > https://github.com/erlang/otp/tree/maint/lib/ssl/src > > Is it unusable or just unstable? > > Do you have a rough estimate when we can expect it? > Next minor release? Next major release? > > Thanks > > > On Thu, Aug 1, 2013 at 12:57 AM, Ingela Andin < ingela@REDACTED > wrote: > > > > Hi, OTP is working on that but it is not ready yet. > Regards Ingela - OTP team Ericsson AB > > Skickat fr?n min iPhone > > 31 jul 2013 kl. 17:52 skrev pablo platt < pablo.platt@REDACTED >: > > > > > Hi, > > Is there a library that implements DTLS client and server in Erlang? > DTLS is the UDP version of TLS > Datagram Transport Layer Security > http://tools.ietf.org/html/rfc4347 > > 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 > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From pablo.platt@REDACTED Thu Oct 17 16:38:40 2013 From: pablo.platt@REDACTED (pablo platt) Date: Thu, 17 Oct 2013 17:38:40 +0300 Subject: [erlang-questions] DTLS client/server In-Reply-To: <306505251.505514.1382019809812.JavaMail.zimbra@tpip.net> References: <-2812677860635758685@unknownmsgid> <306505251.505514.1382019809812.JavaMail.zimbra@tpip.net> Message-ID: I'd rather use the otp API so when R17 is released I can just turn it on. Your implementation is interesting and I'll have a look. Thanks On Thu, Oct 17, 2013 at 5:23 PM, Andreas Schultz wrote: > Hi Pablo, > > I you are desperate to have something working right now, you can always > use my prototype from there: > > https://github.com/RoadRunnr/otp/tree/new_crypto_dtls > > But be aware that the OTP version will have a different API. My version > uses > a wrapper module to read DTLS traffic from somewhere and pass it into the > SSL library. For udp, lib/ssl/src/ssl_udp.erl already exists and > [{versions, ['dtlsv1.2', dtlsv1]}, {cb_info, ssl_udp}] in your ssl options > should work. For other transport layers, you have to implement that module > yourself. > > Andreas > > ----- Original Message ----- > > Is there a chance for release preview of DTLS before the R17 release on > > February? > > > > Thanks > > > > > > > > On Thu, Aug 1, 2013 at 1:03 AM, pablo platt < pablo.platt@REDACTED > > wrote: > > > > > > > > I see some DTLS files in the source: > > https://github.com/erlang/otp/tree/maint/lib/ssl/src > > > > Is it unusable or just unstable? > > > > Do you have a rough estimate when we can expect it? > > Next minor release? Next major release? > > > > Thanks > > > > > > On Thu, Aug 1, 2013 at 12:57 AM, Ingela Andin < ingela@REDACTED > wrote: > > > > > > > > Hi, OTP is working on that but it is not ready yet. > > Regards Ingela - OTP team Ericsson AB > > > > Skickat fr?n min iPhone > > > > 31 jul 2013 kl. 17:52 skrev pablo platt < pablo.platt@REDACTED >: > > > > > > > > > > Hi, > > > > Is there a library that implements DTLS client and server in Erlang? > > DTLS is the UDP version of TLS > > Datagram Transport Layer Security > > http://tools.ietf.org/html/rfc4347 > > > > 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 > > > > -- > -- > Dipl. Inform. > Andreas Schultz > > email: as@REDACTED > phone: +49-391-819099-224 > mobil: +49-170-2226073 > > ------------------- enabling your networks ------------------- > > Travelping GmbH phone: +49-391-819099229 > Roentgenstr. 13 fax: +49-391-819099299 > D-39108 Magdeburg email: info@REDACTED > GERMANY web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 > -------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Thu Oct 17 22:48:10 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 17 Oct 2013 15:48:10 -0500 Subject: [erlang-questions] github maps branch? Message-ID: Is there an implementation of maps on a github branch somewhere? There's a mention in Joe's new book that this might be the case. I have a yaml parsing and code generation project that would benefit enormously from having maps. Thanks, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Thu Oct 17 23:12:06 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 17 Oct 2013 23:12:06 +0200 Subject: [erlang-questions] DTLS client/server In-Reply-To: References: <-2812677860635758685@unknownmsgid> Message-ID: Hi! 2013/10/17 pablo platt > Is there a chance for release preview of DTLS before the R17 release on > February? > > Alas, I still do not have anything releasable that is runnable. I have had to work with some other stuff in between. But I think previews can be possible. I have a rather large step in the pipeline that I probably can release in a few weeks as it then can be merged to maint. This step will include some code from Andreas that implements basic stuff. But the internal structure of the code is quite different and the API is not totally set yet. Regards Ingela Erlang/OTP team - Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From baliulia@REDACTED Thu Oct 17 23:19:11 2013 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Thu, 17 Oct 2013 23:19:11 +0200 Subject: [erlang-questions] Can erlang read xlsx? In-Reply-To: References: Message-ID: <5260544F.2080903@gmail.com> Hi, Agree with Max Bourinov's points, Erlang is maybe not a great use for this. I've used openpyxl for xlsx editing previously mildly successfully. Although in theory xlsx is supposed to be just zipped XML, so if you only need to do a single simple thing you can try to implement it. -- Ignas From drew.varner@REDACTED Fri Oct 18 00:16:15 2013 From: drew.varner@REDACTED (Drew Varner) Date: Thu, 17 Oct 2013 18:16:15 -0400 Subject: [erlang-questions] Can erlang read xlsx? In-Reply-To: <5260544F.2080903@gmail.com> References: <5260544F.2080903@gmail.com> Message-ID: Another option is Apache POI's HSSF and XSSF projects. They read .xls and .xlxs. You can interface via Erlang's JInterface. Cheers, Drew > On Oct 17, 2013, at 5:19 PM, Ignas Vy?niauskas wrote: > > Hi, > > Agree with Max Bourinov's points, Erlang is maybe not a great use for this. > > I've used openpyxl for xlsx editing previously mildly successfully. > > Although in theory xlsx is supposed to be just zipped XML, so if you > only need to do a single simple thing you can try to implement it. > > -- > Ignas > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From pablo.platt@REDACTED Fri Oct 18 05:07:36 2013 From: pablo.platt@REDACTED (pablo platt) Date: Fri, 18 Oct 2013 06:07:36 +0300 Subject: [erlang-questions] DTLS client/server In-Reply-To: References: <-2812677860635758685@unknownmsgid> Message-ID: A preview in a few weeks will be great. Thanks On Fri, Oct 18, 2013 at 12:12 AM, Ingela Andin wrote: > Hi! > > > 2013/10/17 pablo platt > >> Is there a chance for release preview of DTLS before the R17 release on >> February? >> >> > Alas, I still do not have anything releasable that is runnable. I have > had to work with some other stuff in between. > But I think previews can be possible. I have a rather large step in the > pipeline that I probably can release in a few weeks > as it then can be merged to maint. This step will include some code from > Andreas that implements basic stuff. But > the internal structure of the code is quite different and the API is not > totally set yet. > > Regards Ingela Erlang/OTP team - Ericsson AB > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gumm@REDACTED Fri Oct 18 08:28:57 2013 From: gumm@REDACTED (Jesse Gumm) Date: Fri, 18 Oct 2013 01:28:57 -0500 Subject: [erlang-questions] [ANN] Nitrogen Web Framework 2.2 Released Message-ID: I'm proud to announce the 2.2 release of the Nitrogen Web Framework. (2.2.0 was soft-released two weeks ago, and 2.2.1 bugfix release was just finished moments ago) Downloads and Docs (official site): http://nitrogenproject.com Github repo: https://github.com/nitrogen/nitrogen Full Changelog (2.2.0 and 2.2.1): https://github.com/nitrogen/nitrogen/blob/v2.2.1/CHANGELOG.markdown IRC: #nitrogen on irc.freenode.com Mailing list: https://groups.google.com/forum/#!forum/nitrogenweb Twitter: @nitrogenproject ## Major Updates in 2.2 * Added a plugin system, which automatically brings in static resources, and necessary include files (http://nitrogenproject.com/doc/plugins.html ) * Added support for Erlang "Slim releases" (releases that don't include the full Erlang system). * Added an "embed" script for easily adding Nitrogen to an existing Application (http://sigma-star.com/blog/post/embedding-nitrogen ) * Added typespecs to all Nitrogen element records and a lot of Nitrogen internal functions for dialyzer support. * Added the ability to expand on validation failures, including customized messages for client-side only validation failures, or server-side failures. (example: http://nitrogenproject.com/demos/validation ) * Added official builds for FreeBSD and Raspberry Pi (along with the standard Linux, OSX, and Windows) * data_fields (the Nitrogen approach to HTML "data-" attributes) have been added to all elements. * Added a crash handler for gracefully handling crashes rather than giving the user the scary "Internal Server Error" message (http://nitrogenproject.com/doc/handlers/crash.html ) * Added action wiring prioritization through the use of wf:eager and wf:defer (Anything wired with wf:eager will execute before wf:wire, which will execute before wf:defer). This is a common solution to wiring events to elements that haven't been drawn yet. * The usual: New elements, new actions, reworked some elements, a few new API calls, bugfixes, and further expanded docs (See changelog) * The nitrogen-elements repo has had a big update thanks to Roman Shestakov: https://github.com/RomanShestakov/nitrogen_elements/network ## Why Plugins? Due to the fact that I've had some folks ask why I added plugins, I've made a quick writeup of the reasoning: http://sigma-star.com/blog/post/why-nitrogen-plugins ## Roadmap for Nitrogen 2.3 and beyond * Websockets as an alternative to comet (without abandoning comet for mochiweb, webmachine, and inets) added to simple bridge so that websockets+yaws can be used with both Nitrogen and ChicagoBoss. (I've put this off far too long!) * Add support for Wooga's Elli server. * Integrated testing suite for the browser. * Further improve release handling, including generating releases and relups from the standard generated development releases. * More plugins! ## Closing thoughts Hacking on and supporting Nitrogen continues to be a huge passion of mine, with the joy received in working on it, seeing others benefit from it, and of course using Nitrogen to improve my own products. So with that, I say thank you everyone who has submitted pull requests, interacted on the mailing list, IRC, Github, or emailed me directly with questions, and who have provided feedback, code, documentation, or even just general enthusiasm as well as to the extremely helpful Erlang community at large - you folks are all great! And of course, a big thanks to Rusty Klophaus for the initial creation! Thanks again, and happy hacking! -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm From max.lapshin@REDACTED Fri Oct 18 08:32:16 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 18 Oct 2013 10:32:16 +0400 Subject: [erlang-questions] [ANN] Nitrogen Web Framework 2.2 Released In-Reply-To: References: Message-ID: Thanks! I also want to mention, that websockets are not a panacea, because in some countries in Asia they are widely banned on ISP gateways. So, comet shouldn't been dropped for next several years. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gumm@REDACTED Fri Oct 18 08:43:54 2013 From: gumm@REDACTED (Jesse Gumm) Date: Fri, 18 Oct 2013 01:43:54 -0500 Subject: [erlang-questions] [ANN] Nitrogen Web Framework 2.2 Released In-Reply-To: References: Message-ID: Thanks Max! I agree completely. I have no intentions of dropping comet and ajax support in any kind of short time frame, after all, I still plan on supporting non-websocket servers (mochiweb/webmachine/inets/soon elli) for the foreseeable future without having to tell users "sorry, this feature is websockets only". Websockets are planned to be an option, much like Nitrogen's comet configuration can be toggled between actual-comet and periodic polling. All the best, -Jesse On Oct 18, 2013 1:32 AM, "Max Lapshin" wrote: > Thanks! > > I also want to mention, that websockets are not a panacea, because in some > countries in Asia they are widely banned on ISP gateways. > > So, comet shouldn't been dropped for next several years. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dch@REDACTED Fri Oct 18 09:24:10 2013 From: dch@REDACTED (Dave Cottlehuber) Date: Fri, 18 Oct 2013 09:24:10 +0200 Subject: [erlang-questions] github maps branch? In-Reply-To: References: Message-ID: On 17. Oktober 2013 at 22:48:20, Daniel Goertzen (daniel.goertzen@REDACTED) wrote: > >Is there an implementation of maps on a github branch somewhere? There's a >mention in Joe's new book that this might be the case. > >I have a yaml parsing and code generation project that would benefit >enormously from having maps. > >Thanks, >Dan. Heh, I literally just looked for this before breakfast. Not in github/erlang/otp from what I can see. +1, similar situation for me too, wrt to inbuilt json conversion for maps. --? Dave Cottlehuber Sent with Airmail From egil@REDACTED Fri Oct 18 13:26:27 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 18 Oct 2013 13:26:27 +0200 Subject: [erlang-questions] github maps branch? In-Reply-To: References: Message-ID: <52611AE3.2030204@erlang.org> On 2013-10-18 09:24, Dave Cottlehuber wrote: > On 17. Oktober 2013 at 22:48:20, Daniel Goertzen (daniel.goertzen@REDACTED) wrote: >> Is there an implementation of maps on a github branch somewhere? There's a >> mention in Joe's new book that this might be the case. >> >> I have a yaml parsing and code generation project that would benefit >> enormously from having maps. >> >> Thanks, >> Dan. > Heh, I literally just looked for this before breakfast. Not in github/erlang/otp from what I can see. > > +1, similar situation for me too, wrt to inbuilt json conversion for maps. It's not on github yet. We will try to push the first stage to github next week. I'm trying to get it somewhat stable atm. The branch will include "key literals only" for syntax, meaning variable keys are not included. BIFs, API, syntax + compiler + instructions and distribution seems stable. Currently working on specs / dialyzer and not breaking to much stuff. =) Interpreter currently mismatching and debugger not working. So still some work before it is ready for testing. I will have a proper disclaimer once I push it on whats included and not. // Bj?rn-Egil > > -- > Dave Cottlehuber > Sent with Airmail > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From Maxim.Minin@REDACTED Fri Oct 18 13:26:38 2013 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Fri, 18 Oct 2013 13:26:38 +0200 Subject: [erlang-questions] undefined callback function warning In-Reply-To: References: Message-ID: Hello, I define a behaviour like this: -module(test_behaviour). -callback a() -> ok. and two modules like this: -module(test_behaviour_imp). -behaviour(test_behaviour). -export([a/0]). a()->ok. -module(test_behaviour_imp2). -behaviour(test_behaviour). -compile(export_all). a()->ok. The module "test_behaviour_imp" compiles without problems, but by the module "test_behaviour_imp2" I get the warning "undefined callback function a/0 (behaviour 'test_behaviour')". Is it a bug? Thanks Maxim Minin From watson.timothy@REDACTED Fri Oct 18 13:27:45 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 18 Oct 2013 12:27:45 +0100 Subject: [erlang-questions] Fwd: A (hopefully simple) diameter relay question In-Reply-To: <52611937.6020606@gmail.com> References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> <52611937.6020606@gmail.com> Message-ID: Hi Anders, On 10/16/2013 11:22 AM, Anders Svensson wrote: How do the CER/CEA messages look when it fails? /Anders, Erlang/OTP Well, here's a very strange thing. When I run the server on port 10601 and the relay on 3868, the capabilities exchange never takes place. I just see an ongoing cycle of TCP traffic that never makes it to full cap-ex stage. I've attached that as no-capex. The server is configured (using seagull) like so: The relay is configured thus: SvcName = ?MODULE, SvcOpts = [{'Origin-Host', "service.example.com"}, {'Origin-Realm', "example.com"}, {'Vendor-Id', 193}, {'Product-Name', "Server"}, {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections, false}, {use_shared_peers, true}, {application, [{alias, ?MODULE}, {dictionary, ?DIAMETER_DICT_RELAY}, {module, rabbit_diameter_relay}]}], ok = diameter:start_service(SvcName, SvcOpts), {ok, _Ref} = diameter:add_transport( ?MODULE, {connect, [{reconnect_timer, 10000}, {transport_module, diameter_tcp}, {transport_config, [{raddr, {127,0,0,1}}, {rport, 10601}, {reuseaddr, true}]}]}), rabbit_diameter_peer:listen(?MODULE, {tcp, loopback, 3868}), .... Now, if I swap the ports on which the test server and the relay are running (both in the diameter:{add_transport,listen}/2 calls and in the seagull configuration), then the capabilities exchange seems to be fine!!! That is demonstrated in the attached capture good-capex. Surely that is a bug, but is it something that I'm doing wrong? Now when this capex *does* work, the CEA has the result code 2001, and we get Auth-Application-Id=1, Acct-Application-Id=4. The server is configured to reply thus: Now the relay and the server seem to be talking to one another, but if I start the client, pointing to the relay, then the client seems to get forwarded to the server - I see a new participant in the capture - but never seems to get a CEA back for its CER. The client is definitely pointing to the relay: I wonder if the server needs to be explicitly configured to handle a CER *after* initialisation - I have no idea if that's a seagull configuration thing that I've done wrong, or what... I've attached the client and server test scenarios, which are pretty short, but I'll head over to the seagull mailing list to check if I'm doing something silly here, and maybe try starting a test diameter server on another erlang node to eliminate another possible issue. I've attached a capture for the client session (attempt) too, though I'm not sure if that's useful or not. I'd really like to understand why capabilities exchange is failing when I swap the server and relay ports though... Thanks for helping out with this BTW - I really appreciate it. Cheers, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: no-capex Type: application/octet-stream Size: 19108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: good-capex Type: application/octet-stream Size: 4157 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: session-capture Type: application/octet-stream Size: 10627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ccr-cca.client.xml Type: text/xml Size: 3552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ccr-cca.server.xml Type: text/xml Size: 3304 bytes Desc: not available URL: From n.oxyde@REDACTED Fri Oct 18 13:36:29 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 18 Oct 2013 13:36:29 +0200 Subject: [erlang-questions] undefined callback function warning In-Reply-To: References: Message-ID: <51F1C9CE-7789-4676-B60C-C61996B5D5B5@gmail.com> Hello Minin, It is a bug, it has been reported earlier on erlang-bugs. I submitted a patch and as it's just a small bug fix it will probably be included in R16B03. https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour That being said, one should not use export_all. Regards, -- Anthony Ramine Le 18 oct. 2013 ? 13:26, Minin Maxim a ?crit : > Hello, > > I define a behaviour like this: > > -module(test_behaviour). > -callback a() -> ok. > > and two modules like this: > > -module(test_behaviour_imp). > -behaviour(test_behaviour). > -export([a/0]). > a()->ok. > > -module(test_behaviour_imp2). > -behaviour(test_behaviour). > -compile(export_all). > a()->ok. > > The module "test_behaviour_imp" compiles without problems, but by the module "test_behaviour_imp2" I get the warning "undefined callback function a/0 (behaviour 'test_behaviour')". > > Is it a bug? > > Thanks > Maxim Minin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From Maxim.Minin@REDACTED Fri Oct 18 14:33:56 2013 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Fri, 18 Oct 2013 14:33:56 +0200 Subject: [erlang-questions] undefined callback function warning Message-ID: Hello Anthony Thank you very much for the bug fix. Sometimes export_all can be useful you know like this :) -ifdef(TEST). -compile(export_all). -endif. Thanks Maxim -----Urspr?ngliche Nachricht----- Von: Anthony Ramine [mailto:n.oxyde@REDACTED] Gesendet: Freitag, 18. Oktober 2013 13:36 An: Minin Maxim Cc: erlang-questions Betreff: Re: [erlang-questions] undefined callback function warning Hello Minin, It is a bug, it has been reported earlier on erlang-bugs. I submitted a patch and as it's just a small bug fix it will probably be included in R16B03. https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour That being said, one should not use export_all. Regards, -- Anthony Ramine Le 18 oct. 2013 ? 13:26, Minin Maxim a ?crit : > Hello, > > I define a behaviour like this: > > -module(test_behaviour). > -callback a() -> ok. > > and two modules like this: > > -module(test_behaviour_imp). > -behaviour(test_behaviour). > -export([a/0]). > a()->ok. > > -module(test_behaviour_imp2). > -behaviour(test_behaviour). > -compile(export_all). > a()->ok. > > The module "test_behaviour_imp" compiles without problems, but by the module "test_behaviour_imp2" I get the warning "undefined callback function a/0 (behaviour 'test_behaviour')". > > Is it a bug? > > Thanks > Maxim Minin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From Maxim.Minin@REDACTED Fri Oct 18 14:47:57 2013 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Fri, 18 Oct 2013 14:47:57 +0200 Subject: [erlang-questions] Spam from somebody Message-ID: Hello, if i send a mail to this list, I always receive a message in chinese language (see below). This mailbox seems to be full. Can the owner of this mailbox do something against it or maybe should it be removed from the list? Thanks Maxim -----Urspr?ngliche Nachricht----- Von: MAILER-DAEMON@REDACTED [mailto:MAILER-DAEMON@REDACTED] Gesendet: Freitag, 18. Oktober 2013 14:43 An: Minin Maxim Betreff: ??????????? ???(ygzjcc@REDACTED)??????????????????????????? From dch@REDACTED Fri Oct 18 17:35:23 2013 From: dch@REDACTED (Dave Cottlehuber) Date: Fri, 18 Oct 2013 17:35:23 +0200 Subject: [erlang-questions] [ANN] Vienna BEAMers group Message-ID: Hi everybody, TL;DR all things beamy (erlang, elixir, lfe, joxa), and distributedy (riak, couch, rabbit, raft, paxos ?) in Vienna, Austria. I hope nobody minds me announcing the Vienna, Austria, BEAMers group here, and humbly begging your social media indulgences for a share/tweet/etc. The meetup: http://www.meetup.com/Vienna-BEAMers The twitters: follow @viennabeamers Re-tweet?https://twitter.com/viennabeamers/status/391154409906143233 The first meeting: 6 November, at http://sektor5.at/ As winter is coming (in the Northern Hemisphere), we all need something to do on those long winter nights. "I run on the mighty concurrent BEAM Virtual Machine. I eat Elixir for breakfast, Erlang/OTP for lunch, and Lisp-Flavoured Erlang & Joxa for dessert." Also, consider this an open invitation for people passing through to give a talk on any of the above. A+ Dave Cottlehuber Sent with Airmail From valentin@REDACTED Fri Oct 18 18:38:33 2013 From: valentin@REDACTED (Valentin Micic) Date: Fri, 18 Oct 2013 18:38:33 +0200 Subject: [erlang-questions] [ANN] Vienna BEAMers group In-Reply-To: References: Message-ID: <906B9E71-3461-4E8B-A5E7-D7CFB26B9812@pixie.co.za> go VDM BEAMers :-) V/ On 18 Oct 2013, at 5:35 PM, Dave Cottlehuber wrote: > Hi everybody, > > TL;DR all things beamy (erlang, elixir, lfe, joxa), and distributedy (riak, couch, rabbit, raft, paxos ?) in Vienna, Austria. > > I hope nobody minds me announcing the Vienna, Austria, BEAMers group here, and humbly begging your social media indulgences for a share/tweet/etc. > > The meetup: http://www.meetup.com/Vienna-BEAMers > The twitters: follow @viennabeamers > Re-tweet https://twitter.com/viennabeamers/status/391154409906143233 > The first meeting: 6 November, at http://sektor5.at/ > > As winter is coming (in the Northern Hemisphere), we all need something to do on those long winter nights. > > "I run on the mighty concurrent BEAM Virtual Machine. I eat Elixir for breakfast, Erlang/OTP for lunch, and Lisp-Flavoured Erlang & Joxa for dessert." > > Also, consider this an open invitation for people passing through to give a talk on any of the above. > > A+ > Dave Cottlehuber > Sent with Airmail > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From anders.otp@REDACTED Fri Oct 18 18:45:06 2013 From: anders.otp@REDACTED (Anders Svensson) Date: Fri, 18 Oct 2013 18:45:06 +0200 Subject: [erlang-questions] A (hopefully simple) diameter relay question In-Reply-To: References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> <52611937.6020606@gmail.com> Message-ID: And one more time to the list ... /Anders On Fri, Oct 18, 2013 at 6:43 PM, Anders Svensson wrote: > Hi Tim. > > On Fri, Oct 18, 2013 at 1:27 PM, Tim Watson wrote: >> Hi Anders, >> >> >> On 10/16/2013 11:22 AM, Anders Svensson wrote: >> >> How do the CER/CEA messages look when it fails? /Anders, Erlang/OTP >> >> >> Well, here's a very strange thing. When I run the server on port 10601 and >> the relay on 3868, the capabilities exchange never takes place. I just see >> an ongoing cycle of TCP traffic that never makes it to full cap-ex stage. >> I've attached that as no-capex. The server is configured (using seagull) > > Are you sure that's the right dump? There's a CER/CEA exchange in > frames 35 and 37, but the relay port is 60104 and the server port > 3868. The relay sends CER (frame 35), the server responds with a 2001 > CEA (frame 37), and then the relay closes the connection (frame 39). > > A bit later on there's Diameter traffic between 127.0.0.1:37291 and > 127.0.0.1:10601 but it looks pretty much the same: CER (frame 102), > CEA (frame 104), close the connection (frame 106). > > Later still there's a relay CER (frame 118) that's unanswered and > causes the server to close the connection (frame 123). > > One thing that's not quite right in your configuration is that both > the relay and server identify themselves with > Origin-Host=service.example.com. The server is another Diameter node > that should have its own identity. Not sure if that could be a problem > (don't know seagull for one) but it's not impossible. Similarly, the > client should also have its own identity. > > The relay closing the connection upon reception of CEA means that > there's something it doesn't like. If you trace on > diameter_peer_fsm:terminate/2 then we should be able to see why. > >> like so: >> >> > name="channel-1" >> protocol="diameter-v1" >> transport="trans-ip-v4" >> open-args="mode=server;source=127.0.0.1:10601"> >> >> >> The relay is configured thus: >> >> SvcName = ?MODULE, >> SvcOpts = [{'Origin-Host', "service.example.com"}, >> {'Origin-Realm', "example.com"}, >> {'Vendor-Id', 193}, >> {'Product-Name', "Server"}, >> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, >> {restrict_connections, false}, >> {use_shared_peers, true}, >> {application, [{alias, ?MODULE}, >> {dictionary, ?DIAMETER_DICT_RELAY}, >> {module, rabbit_diameter_relay}]}], >> ok = diameter:start_service(SvcName, SvcOpts), >> {ok, _Ref} = >> diameter:add_transport( >> ?MODULE, >> {connect, [{reconnect_timer, 10000}, >> >> {transport_module, diameter_tcp}, >> {transport_config, [{raddr, {127,0,0,1}}, >> {rport, 10601}, >> {reuseaddr, true}]}]}), >> >> rabbit_diameter_peer:listen(?MODULE, {tcp, loopback, 3868}), >> .... >> >> Now, if I swap the ports on which the test server and the relay are running >> (both in the diameter:{add_transport,listen}/2 calls and in the seagull >> configuration), then the capabilities exchange seems to be fine!!! That is >> demonstrated in the attached capture good-capex. Surely that is a bug, but >> is it something that I'm doing wrong? > > I see the same behaviour as above: CER, CEA, close the connection. > > Start with fixing you Origin-Host values and let's see how far that gets us. > > Anders > > > >> >> Now when this capex *does* work, the CEA has the result code 2001, and we >> get Auth-Application-Id=1, Acct-Application-Id=4. The server is configured >> to reply thus: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Now the relay and the server seem to be talking to one another, but if I >> start the client, pointing to the relay, then the client seems to get >> forwarded to the server - I see a new participant in the capture - but never >> seems to get a CEA back for its CER. The client is definitely pointing to >> the relay: >> >> > name="channel-1" >> protocol="diameter-v1" >> transport="trans-1" >> open-args="mode=client;dest=127.0.0.1:10601"> >> >> >> I wonder if the server needs to be explicitly configured to handle a CER >> *after* initialisation - I have no idea if that's a seagull configuration >> thing that I've done wrong, or what... I've attached the client and server >> test scenarios, which are pretty short, but I'll head over to the seagull >> mailing list to check if I'm doing something silly here, and maybe try >> starting a test diameter server on another erlang node to eliminate another >> possible issue. >> >> I've attached a capture for the client session (attempt) too, though I'm not >> sure if that's useful or not. I'd really like to understand why capabilities >> exchange is failing when I swap the server and relay ports though... >> >> Thanks for helping out with this BTW - I really appreciate it. >> >> Cheers, >> Tim >> >> From watson.timothy@REDACTED Fri Oct 18 19:38:06 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 18 Oct 2013 18:38:06 +0100 Subject: [erlang-questions] A (hopefully simple) diameter relay question In-Reply-To: References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> <52611937.6020606@gmail.com> Message-ID: <2AE24381-E107-475E-A7FF-4DD6F901A2EA@gmail.com> Awesome, thanks or the input. I didn't realise the origins needed to differ - ill tweak those and get some tracing turned on. Will let you know how I get on come Monday. Thanks! Tim On 18 Oct 2013, at 17:45, Anders Svensson wrote: > And one more time to the list ... /Anders > > On Fri, Oct 18, 2013 at 6:43 PM, Anders Svensson wrote: >> Hi Tim. >> >> On Fri, Oct 18, 2013 at 1:27 PM, Tim Watson wrote: >>> Hi Anders, >>> >>> >>> On 10/16/2013 11:22 AM, Anders Svensson wrote: >>> >>> How do the CER/CEA messages look when it fails? /Anders, Erlang/OTP >>> >>> >>> Well, here's a very strange thing. When I run the server on port 10601 and >>> the relay on 3868, the capabilities exchange never takes place. I just see >>> an ongoing cycle of TCP traffic that never makes it to full cap-ex stage. >>> I've attached that as no-capex. The server is configured (using seagull) >> >> Are you sure that's the right dump? There's a CER/CEA exchange in >> frames 35 and 37, but the relay port is 60104 and the server port >> 3868. The relay sends CER (frame 35), the server responds with a 2001 >> CEA (frame 37), and then the relay closes the connection (frame 39). >> >> A bit later on there's Diameter traffic between 127.0.0.1:37291 and >> 127.0.0.1:10601 but it looks pretty much the same: CER (frame 102), >> CEA (frame 104), close the connection (frame 106). >> >> Later still there's a relay CER (frame 118) that's unanswered and >> causes the server to close the connection (frame 123). >> >> One thing that's not quite right in your configuration is that both >> the relay and server identify themselves with >> Origin-Host=service.example.com. The server is another Diameter node >> that should have its own identity. Not sure if that could be a problem >> (don't know seagull for one) but it's not impossible. Similarly, the >> client should also have its own identity. >> >> The relay closing the connection upon reception of CEA means that >> there's something it doesn't like. If you trace on >> diameter_peer_fsm:terminate/2 then we should be able to see why. >> >>> like so: >>> >>> >> name="channel-1" >>> protocol="diameter-v1" >>> transport="trans-ip-v4" >>> open-args="mode=server;source=127.0.0.1:10601"> >>> >>> >>> The relay is configured thus: >>> >>> SvcName = ?MODULE, >>> SvcOpts = [{'Origin-Host', "service.example.com"}, >>> {'Origin-Realm', "example.com"}, >>> {'Vendor-Id', 193}, >>> {'Product-Name', "Server"}, >>> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, >>> {restrict_connections, false}, >>> {use_shared_peers, true}, >>> {application, [{alias, ?MODULE}, >>> {dictionary, ?DIAMETER_DICT_RELAY}, >>> {module, rabbit_diameter_relay}]}], >>> ok = diameter:start_service(SvcName, SvcOpts), >>> {ok, _Ref} = >>> diameter:add_transport( >>> ?MODULE, >>> {connect, [{reconnect_timer, 10000}, >>> >>> {transport_module, diameter_tcp}, >>> {transport_config, [{raddr, {127,0,0,1}}, >>> {rport, 10601}, >>> {reuseaddr, true}]}]}), >>> >>> rabbit_diameter_peer:listen(?MODULE, {tcp, loopback, 3868}), >>> .... >>> >>> Now, if I swap the ports on which the test server and the relay are running >>> (both in the diameter:{add_transport,listen}/2 calls and in the seagull >>> configuration), then the capabilities exchange seems to be fine!!! That is >>> demonstrated in the attached capture good-capex. Surely that is a bug, but >>> is it something that I'm doing wrong? >> >> I see the same behaviour as above: CER, CEA, close the connection. >> >> Start with fixing you Origin-Host values and let's see how far that gets us. >> >> Anders >> >> >> >>> >>> Now when this capex *does* work, the CEA has the result code 2001, and we >>> get Auth-Application-Id=1, Acct-Application-Id=4. The server is configured >>> to reply thus: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Now the relay and the server seem to be talking to one another, but if I >>> start the client, pointing to the relay, then the client seems to get >>> forwarded to the server - I see a new participant in the capture - but never >>> seems to get a CEA back for its CER. The client is definitely pointing to >>> the relay: >>> >>> >> name="channel-1" >>> protocol="diameter-v1" >>> transport="trans-1" >>> open-args="mode=client;dest=127.0.0.1:10601"> >>> >>> >>> I wonder if the server needs to be explicitly configured to handle a CER >>> *after* initialisation - I have no idea if that's a seagull configuration >>> thing that I've done wrong, or what... I've attached the client and server >>> test scenarios, which are pretty short, but I'll head over to the seagull >>> mailing list to check if I'm doing something silly here, and maybe try >>> starting a test diameter server on another erlang node to eliminate another >>> possible issue. >>> >>> I've attached a capture for the client session (attempt) too, though I'm not >>> sure if that's useful or not. I'd really like to understand why capabilities >>> exchange is failing when I swap the server and relay ports though... >>> >>> Thanks for helping out with this BTW - I really appreciate it. >>> >>> Cheers, >>> Tim >>> >>> From ferenc.holzhauser@REDACTED Fri Oct 18 20:50:09 2013 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Fri, 18 Oct 2013 20:50:09 +0200 Subject: [erlang-questions] Weird problem with "receive after ..." Message-ID: Hi, On my development system sometimes "receive after..." starts hanging after a while. I know "sometimes" is not very helpful but I couldn't find any obviously related event yet that might trigger it. >From that point it stops working in the whole VM e.g. I can type "receive after 10 -> ok end." in the shell and watch it never returning. Of course it also breaks most of the things that need timer. Normal receive keeps working fine, the issue is related to timeout only. It is R16B01 and I'm not using any self made NIFs, drivers or other funny things that could break the VM. Thank you for any hints or suggestions about the possible reason/fix in advance. Regards, Ferenc -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Fri Oct 18 21:35:24 2013 From: anthonym@REDACTED (Anthony Molinaro) Date: Fri, 18 Oct 2013 12:35:24 -0700 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: References: Message-ID: Are you running in some sort of virtualized environment. I seem to recall noticing some oddness with timer:send_interval/2 under VMware at one point, but it's a total guess so may not be your issue at all. -Anthony On Oct 18, 2013, at 11:50 AM, Ferenc Holzhauser wrote: > Hi, > > On my development system sometimes "receive after..." starts hanging after a while. > I know "sometimes" is not very helpful but I couldn't find any obviously related event yet that might trigger it. > > From that point it stops working in the whole VM e.g. I can type "receive after 10 -> ok end." in the shell and watch it never returning. Of course it also breaks most of the things that need timer. > Normal receive keeps working fine, the issue is related to timeout only. > > It is R16B01 and I'm not using any self made NIFs, drivers or other funny things that could break the VM. > > Thank you for any hints or suggestions about the possible reason/fix in advance. > > Regards, > Ferenc > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ferenc.holzhauser@REDACTED Fri Oct 18 22:29:15 2013 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Fri, 18 Oct 2013 22:29:15 +0200 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: References: Message-ID: Hi Anthony, That must be it: it is running in virtualbox indeed. Are you aware of any workaround/fix to try? I'm quite attached to this VM setup. Would be great if I could make it work reliably. Ferenc On Oct 18, 2013 9:35 PM, "Anthony Molinaro" wrote: > Are you running in some sort of virtualized environment. I seem to recall > noticing some oddness with timer:send_interval/2 under VMware at one point, > but it's a total guess so may not be your issue at all. > > -Anthony > > On Oct 18, 2013, at 11:50 AM, Ferenc Holzhauser < > ferenc.holzhauser@REDACTED> wrote: > > > Hi, > > > > On my development system sometimes "receive after..." starts hanging > after a while. > > I know "sometimes" is not very helpful but I couldn't find any obviously > related event yet that might trigger it. > > > > From that point it stops working in the whole VM e.g. I can type > "receive after 10 -> ok end." in the shell and watch it never returning. Of > course it also breaks most of the things that need timer. > > Normal receive keeps working fine, the issue is related to timeout only. > > > > It is R16B01 and I'm not using any self made NIFs, drivers or other > funny things that could break the VM. > > > > Thank you for any hints or suggestions about the possible reason/fix in > advance. > > > > Regards, > > Ferenc > > > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstover@REDACTED Fri Oct 18 22:13:29 2013 From: tstover@REDACTED (Thomas Stover) Date: Fri, 18 Oct 2013 15:13:29 -0500 Subject: [erlang-questions] libei use in port drivers Message-ID: Hi list. This is only my second month with erlang so bare with me. I'm attempting to use the functions in libei (erl_decode, etc) from inside a port driver. It's a little suspicious that I haven't seen this discussed in the docs, but how else are you to decode terms in C when using binary mode? (I see driver_output_term() for the other direction.) Anyway, the issue is that the driver wont load when I try to use them. I suspect that I need to link to libei, but all there is the .a version (which I did tried). Unless that was built with ?fpic that wont work. I just keep getting that (seemingly frequent) {error,{open_error,-10}} Is there anyway to figure out some more information. I know when you work with the dlopen() family directly, somehow you can get some more detail about unresolved symbols, and such. Any ideas? thanks. --- C. Thomas Stover Sr. Software Engineer Alert Logic, Inc.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Oct 18 23:32:08 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 18 Oct 2013 23:32:08 +0200 Subject: [erlang-questions] libei use in port drivers In-Reply-To: References: Message-ID: <27B59C3E-6513-4A19-931B-72AC8FC9FF20@gmail.com> Hello Thomas, Replied inline. Regards, -- Anthony Ramine Le 18 oct. 2013 ? 22:13, Thomas Stover a ?crit : > Hi list. This is only my second month with erlang so bare with me. > > I'm attempting to use the functions in libei (erl_decode, etc) from inside a port driver. It's a little suspicious that I haven't seen this discussed in the docs, but how else are you to decode terms in C when using binary mode? (I see driver_output_term() for the other direction.) Anyway, the issue is that the driver wont load when I try to use them. I suspect that I need to link to libei, but all there is the .a version (which I did tried). Unless that was built with ?fpic that wont work. What is your platform? Also please note that driver_output_term() is deprecated. > I just keep getting that (seemingly frequent) {error,{open_error,-10}} Is there anyway to figure out some more information. I know when you work with the dlopen() family directly, somehow you can get some more detail about unresolved symbols, and such. Use erl_ddll:format_error({open_error,-10}). From tstover@REDACTED Fri Oct 18 23:45:53 2013 From: tstover@REDACTED (Thomas Stover) Date: Fri, 18 Oct 2013 16:45:53 -0500 Subject: [erlang-questions] libei use in port drivers In-Reply-To: <27B59C3E-6513-4A19-931B-72AC8FC9FF20@gmail.com> Message-ID: Thanks for the response. On 10/18/13 4:32 PM, "Anthony Ramine" wrote: > >Le 18 oct. 2013 ? 22:13, Thomas Stover a ?crit : > >>... > >What is your platform? Also please note that driver_output_term() is >deprecated. Yes, noted. I'm working with an inherited codebase. Platform is Linux on x86_64. > >> ... > >Use erl_ddll:format_error({open_error,-10}). > "undefined symbol: erl_decode" I'm sure that is due to the objects inside libei.a (most likely) not being built with -fpic, which is what would have had to happen for them to load up in the dlopen() of my driver. I suppose I could try to rebuild libei as a shared lib (why isn't it to start with?). That feels strange though, because is no one else using libei inside a driver? Does everyone just use only manual encoding from erlang to C when it comes to drivers. Does everyone just use external process ports when they use libei? From smith.winston.101@REDACTED Sat Oct 19 00:41:04 2013 From: smith.winston.101@REDACTED (Winston Smith) Date: Fri, 18 Oct 2013 18:41:04 -0400 Subject: [erlang-questions] Port driver using erl_drv_output_term() to a gen_server:handle_info() Message-ID: I have port driver that does async [non-blocking] I/O (using driver_select() etc) and on the ready_io READ callback, I'm trying to send data back to the Erlang side using erl_drv_output_term(). Everything seems to work, except that I never see the data on the Erlang side. The Erlang side of this is a gen_server that opens the port in it's init() call. The incoming data is asynchronous, so I can't use the port_command()-then-receive idiom -- I was expecting to be able to implement a handle_info() to catch the message, but I just don't see anything on the Erlang side. I'm guessing that somehow the port driver owner isn't the same thing as the gen_server, even though I'm doing the port_open() during gen_server:init(). Any ideas? Thanks, -W -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Sat Oct 19 01:30:37 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 18 Oct 2013 19:30:37 -0400 Subject: [erlang-questions] libei use in port drivers In-Reply-To: References: <27B59C3E-6513-4A19-931B-72AC8FC9FF20@gmail.com> Message-ID: On Fri, Oct 18, 2013 at 5:45 PM, Thomas Stover wrote: > I suppose I could try to rebuild libei as a shared lib (why isn't it to > start with?). That feels strange though, because is no one else using > libei inside a driver? Does everyone just use only manual encoding from > erlang to C when it comes to drivers. Does everyone just use external > process ports when they use libei? > You can use ei_decode*() family functions inside the driver's *_output() function, but since those functions deal with decoding Erlang terms from external binary format, you need to ensure that you use the term_to_binary(Term) encoding on the Erlang side when you send a message to the driver. Since there's a little overhead in that serialization, in simple cases it may be a bit more efficient to come up with your own binary encoding/decoding. Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Sat Oct 19 01:34:56 2013 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 18 Oct 2013 16:34:56 -0700 Subject: [erlang-questions] Port driver using erl_drv_output_term() to a gen_server:handle_info() In-Reply-To: References: Message-ID: <5261C5A0.1090802@gmail.com> It is hard to say what the issue is (from my point of view) with the information given. However, there is a way of generating a port driver automatically, with async support here: https://github.com/okeuday/GEPD . If you try the example, or look at it, it should help... it is doing an async request after a sleep, as shown in the output within the README (and you may be able to adapt your source code to use it, to avoid some of the port driver details, if that helps you). On 10/18/2013 03:41 PM, Winston Smith wrote: > I have port driver that does async [non-blocking] I/O (using driver_select() etc) and on the ready_io READ callback, I'm trying to send data back to the Erlang side using erl_drv_output_term(). Everything seems to work, except that I never see the data on the Erlang side. > > The Erlang side of this is a gen_server that opens the port in it's init() call. The incoming data is asynchronous, so I can't use the port_command()-then-receive idiom -- I was expecting to be able to implement a handle_info() to catch the message, but I just don't see anything on the Erlang side. > > I'm guessing that somehow the port driver owner isn't the same thing as the gen_server, even though I'm doing the port_open() during gen_server:init(). > > Any ideas? Thanks, > > -W > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith.winston.101@REDACTED Sat Oct 19 05:58:06 2013 From: smith.winston.101@REDACTED (Winston Smith) Date: Fri, 18 Oct 2013 23:58:06 -0400 Subject: [erlang-questions] Port driver using erl_drv_output_term() to a gen_server:handle_info() In-Reply-To: <5261C5A0.1090802@gmail.com> References: <5261C5A0.1090802@gmail.com> Message-ID: On Fri, Oct 18, 2013 at 7:34 PM, Michael Truog wrote: > It is hard to say what the issue is (from my point of view) with the > information given. However, there is a way of generating a port driver > automatically, with async support here: https://github.com/okeuday/GEPD. If you try the example, or look at it, it should help... it is doing an > async request after a sleep, as shown in the output within the README (and > you may be able to adapt your source code to use it, to avoid some of the > port driver details, if that helps you). > I figured it out, I had earlier found that calling driver_mk_port() didn't work inside of the readyio callbacks, so I call it during driver start, but I had not stored it properly in my driver data structure. So the value I was passing into erl_drv_output_term() was in fact garbage (although it didn't crash the system). In any case, I found the issue and it all works perfectly now! Thanks for taking the time to respond. -W -------------- next part -------------- An HTML attachment was scrubbed... URL: From klacke@REDACTED Sat Oct 19 13:09:53 2013 From: klacke@REDACTED (Claes Wikstrom) Date: Sat, 19 Oct 2013 22:09:53 +1100 Subject: [erlang-questions] yaws 1.97 Message-ID: <52626881.2050103@hyber.org> Hi all, We're happy to announce Yaws 1.97 This release contains the usual mix of small improvements, generally just making Yaws more and more of a rock solid web server. Code on github, https://github.com/klacke/yaws Releases and relnotes on http://yaws.hyber.org Important DOS note: The OTP file:sendfile is buggy, so all users of send_file are susceptible to this. If you use Yaws in production, carefully ponder the text below. Christopher Faulet worked this, and his excellent checkin comment says ------- Add the way to configure the version of sendfile method to use Now, at compile time, we only check if sendfile syscall and file:sendfile/5 are supported. Then, dynamically, we can configure which version to use. This can be done using the directive large_file_sendfile. Supported values are: * erlang: if supported, use file:sendfile/5 * yaws: if supported, use the Yaws sendfile linked-in driver * disable: do not use any sendfile method, but gen_tcp:send/2 If an unsupported method is configured, we fall back on gen_tcp:send/2. file:sendfile/5 implementation is buggy (in R15 & R16). When async-threads are enabled, in efile driver, the tcp socket is set in blocking mode and the sendfile syscall is executed on an async-thread. So an unresponsive client could block it for a very long time and therefore block the async-thread. In this way, all async-threads could be easily blocked. So, by default, the use of sendfile is disable. From jani.j.hakala@REDACTED Sat Oct 19 19:00:21 2013 From: jani.j.hakala@REDACTED (Jani Hakala) Date: Sat, 19 Oct 2013 20:00:21 +0300 Subject: [erlang-questions] libei use in port drivers In-Reply-To: (Thomas Stover's message of "Fri, 18 Oct 2013 16:45:53 -0500") References: Message-ID: <8761stqjq2.fsf@pingviini.dyndns.org> Thomas Stover writes: > "undefined symbol: erl_decode" > > I'm sure that is due to the objects inside libei.a (most likely) not being > built with -fpic, which is what would have had to happen for them to load > up in the dlopen() of my driver. > Are you also linking liberl_interface.a ? erl_decode is there. Jani Hakala From anthonym@REDACTED Sat Oct 19 21:51:25 2013 From: anthonym@REDACTED (Anthony Molinaro) Date: Sat, 19 Oct 2013 12:51:25 -0700 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: References: Message-ID: I don't know if a work around probably make sure you are running the most recent version of virtual box? And make make sure to give it multiple cores. You could also convert the vm to a different format (like VMware), and see if it works better. -Anthony On Oct 18, 2013, at 1:29 PM, Ferenc Holzhauser wrote: > Hi Anthony, > > That must be it: it is running in virtualbox indeed. Are you aware of any workaround/fix to try? I'm quite attached to this VM setup. Would be great if I could make it work reliably. > > Ferenc > > On Oct 18, 2013 9:35 PM, "Anthony Molinaro" wrote: >> Are you running in some sort of virtualized environment. I seem to recall noticing some oddness with timer:send_interval/2 under VMware at one point, but it's a total guess so may not be your issue at all. >> >> -Anthony >> >> On Oct 18, 2013, at 11:50 AM, Ferenc Holzhauser wrote: >> >> > Hi, >> > >> > On my development system sometimes "receive after..." starts hanging after a while. >> > I know "sometimes" is not very helpful but I couldn't find any obviously related event yet that might trigger it. >> > >> > From that point it stops working in the whole VM e.g. I can type "receive after 10 -> ok end." in the shell and watch it never returning. Of course it also breaks most of the things that need timer. >> > Normal receive keeps working fine, the issue is related to timeout only. >> > >> > It is R16B01 and I'm not using any self made NIFs, drivers or other funny things that could break the VM. >> > >> > Thank you for any hints or suggestions about the possible reason/fix in advance. >> > >> > Regards, >> > Ferenc >> > >> > >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Sun Oct 20 00:25:05 2013 From: mjtruog@REDACTED (Michael Truog) Date: Sat, 19 Oct 2013 15:25:05 -0700 Subject: [erlang-questions] [ANN] CloudI 1.3.0 Released! Message-ID: <526306C1.4000604@gmail.com> Download 1.3.0 from http://sourceforge.net/projects/cloudi/files/latest/download What is CloudI? A Cloud at the lowest level! CloudI (http://cloudi.org/) is a "universal integrator" using an Erlang core, with its actor model, to pursue efficiency, fault-tolerance and scalability. The CloudI API provides a minimal interface to communicate among actors that are called services, so programming language agnostic, database agnostic, and messaging bus agnostic integration can occur. CloudI currently integrates with the programming languages Erlang, C/C++, Java, Python, and Ruby, the databases PostgreSQL, elasticsearch, Cassandra, MySQL, couchdb, memcached, and tokyotyrant, the messaging bus ZeroMQ and the internal CloudI service bus. HTTP is also supported for easy integration with cowboy and elli. If anyone is willing to get involved, don't hesitate to contact me or start looking at the code. Thanks to Mahesh Paolini-Subramanya for the Cassandra integration along with the elasticsearch integration additions and everyone for the various feedback/issues/bugs that have been reported. The details for this release are below: October 18, 2013 Version 1.3.0 (beta) released. * backwards compatibility difference: * CloudI Service API function services_add now returns a list of service UUIDs which can then be used in the other CloudI Service API functions (see the API HTML documentation or the cloudi_service_api module for details) * cassandra support was added by Mahesh Paolini-Subramanya * elasticsearch support for mapping and aliases was added by Mahesh Paolini-Subramanya * A service name pattern matching bug was fixed after being reported by Anton Ryabkov (an unsubscribe now removes a cpg group entry, if the group is empty, to avoid shadowing a pattern match) * CloudI API function cloudi_service:mcast_async_active was added * All the included internal CloudI services are now separate Erlang/OTP applications, to provide better management of their dependencies * The hello_world4 example was added to show how an Erlang/OTP release with CloudI can be created with relx * The hello_world3 example (rebar usage) was simplified, (rebar's HEAD is currently broken, refer to example README for details) * The service configuration options monkey_latency and monkey_chaos were added to provide a way of changing service performance and/or stability for evaluating system resilience during service problems (http://techblog.netflix.com/2011/07/netflix-simian-army.html) * cloudi_service_http_cowboy had a few additions: * multipart support was added * content_types_accepted, set_x_forwarded_for, and status_code_timeout are configuration options * "status" key usage in ResponseInfo provides the HTTP status, as with normal HTTP protocol responses * A few new internal services were added: * cloudi_service_db_cassandra * cloudi_service_db * cloudi_service_tcp * cloudi_service_udp * cloudi_service_quorum * Various bugfixes, small additions, and documentation improvements Please mention any problems, issues, or ideas! Thanks, Michael From bcristi@REDACTED Mon Oct 21 09:00:20 2013 From: bcristi@REDACTED (Cristian Berneanu) Date: Mon, 21 Oct 2013 10:00:20 +0300 Subject: [erlang-questions] write access to beam.smp (SELinux policy) Message-ID: Hello, I'm new to this list, so please excuse me if this topic was already discussed. I'm writing a SELinux policy for an Erlang application and I noticed that the Erlang VM needs write rights on beam.smp. Is this normal behavior? If yes, can it be bypassed? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcristi@REDACTED Mon Oct 21 10:10:04 2013 From: bcristi@REDACTED (Cristian Berneanu) Date: Mon, 21 Oct 2013 11:10:04 +0300 Subject: [erlang-questions] write access to beam.smp (SELinux policy) In-Reply-To: References: Message-ID: Sorry, I misinterpreted the audit message. The process beam.smp tries to write to file "epmd". On Mon, Oct 21, 2013 at 10:00 AM, Cristian Berneanu wrote: > Hello, > > I'm new to this list, so please excuse me if this topic was already > discussed. > > I'm writing a SELinux policy for an Erlang application and I noticed that > the Erlang VM needs write rights on beam.smp. > Is this normal behavior? If yes, can it be bypassed? > > Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.thorsen@REDACTED Mon Oct 21 10:44:13 2013 From: lars.thorsen@REDACTED (Lars Thorsen) Date: Mon, 21 Oct 2013 10:44:13 +0200 Subject: [erlang-questions] Xmerl question In-Reply-To: References: Message-ID: <5264E95D.4070800@erix.ericsson.se> Hi, try to use xmerl_sax_parser:file/2 instead, it should get you a better line number. It works better than xmerl_scan for parsing as long as you don't need to validate against a schema or DTD (the validation part is not ready yet). Regards Lars OTP Team On 10/09/2013 05:07 PM, Rodolphe Qui?deville wrote: > Hi, > > This is my first post on this list, I a beginner on erlang with a long > experience in other languages like python or perl. > > When using a xml file with syntax error with xmerl_scan:file the output > indicate the line and column number as : > > 1> xmerl_scan:file('failed.xml'). > 2542- fatal: {endtag_does_not_match,{was,request,should_have_been,http}} > ** exception exit: {fatal,{{endtag_does_not_match,{was,request, > should_have_been,http}}, > {file,'failed.xml'}, > {line,77}, > {col,8}}} > > The problem is the file failed.xml is composed with a lot of ENTITY so > the original file doesn't contains 77 lines, the debug is not easy is > this case. Howto dump the final xml really analyzed by xmerl_scan to > debug the xml ? > > Is there any options to pass to xmerl_scan ? I read the doc but can't > find the solution. Any helps appreciate > > Regards; > > PS : the question was already post on stackoverflow as > http://stackoverflow.com/questions/19213242/ > From rodolphe@REDACTED Mon Oct 21 11:47:57 2013 From: rodolphe@REDACTED (Rodolphe =?utf-8?Q?Qui=C3=A9deville?=) Date: Mon, 21 Oct 2013 11:47:57 +0200 Subject: [erlang-questions] Xmerl question In-Reply-To: <5264E95D.4070800@erix.ericsson.se> References: , <5264E95D.4070800@erix.ericsson.se> Message-ID: Lars Thorsen writes: > Hi, > try to use xmerl_sax_parser:file/2 instead, it should get you a better line number. > It works better than xmerl_scan for parsing as long as you don't need to validate > against a schema or DTD (the validation part is not ready yet). Hi Lars, Thanks a lot, it's perfect, xmerl_sax_parser:file/2 does what I'm looking for, as it prints the error on stdout like : Config Error, aborting ! {{badmatch, {<<"\n \n \n \n\n \n \n \n \n \n \n\n ">>, It'll help a lot to debug. Regards, -- Rodolphe Qui?deville Expert Tsung - Consulting en performance des SI Tel : 06 13 79 63 41 http://blog.rodolphe.quiedeville.org From n.oxyde@REDACTED Mon Oct 21 12:54:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 21 Oct 2013 12:54:03 +0200 Subject: [erlang-questions] On Pull Requests Comments Message-ID: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> Hello, I don't like the switch to GitHub pull requests and I argued about it in a nondescript pull request that was made for one of my patches. I could just link to it [1] but as there is no guarantee about comments in GitHub's system, I will copy and paste what I wrote there: > Otherwise while pull requests are good in theory, @OTP-Maintainer gives a good example of where it sucks big time, you have to take care of formatting your emails etc, and Markdown is underspecified. I would rather have plain text emails which I can browse offline. I don't even have my own comments received by email when using pull requests, that's splitting information. > > We gave up on standard email protocols to use a proprietary forum, this sucks. > > Also, while someone can't delete an email that I have already received, anyone can delete a comment he made on GitHub. I fail to see that as an improvement. > > And people can also amend their comments whenever they want, this is insane. Please do not try to make me believe that amending of comments is harmless and won't be a reality. When I look at the amount of aggressivity that is shown around here sometimes, I can't even begin to fathom what can happen when discussion can be altered after the fact at any given point in time. Please don't tell me either that learning Markdown is easy. Just take a look at big profile repositories like the OS X package manager Homebrew: most bug reports and build logs are never properly formatted and you end up with unusable garbage where even squinting your eyes won't help. Nobody care about properly formatting comments. You can't beat mailing-lists' openness. Regards, [1] https://github.com/erlang/otp/pull/103#issuecomment-26706198 -- Anthony Ramine From essen@REDACTED Mon Oct 21 13:14:13 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 21 Oct 2013 13:14:13 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> Message-ID: <52650C85.50207@ninenines.eu> Pull requests have the advantage that almost all Erlang projects already use them. Instead of having to lookup how to submit patches all the time one can now just use the workflow they are used to with other projects. They also are useful for very small patches, like fixing typos, because those can be fixed directly using the Github UI, which is a lot more convenient and actually makes these contributions doable, as few people would go all the way to send them otherwise unless they were already setup for contributing. You do bring up good points, but it's not all black and white. Both solutions have their own merits. I'm sure there's more than the above too. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From n.oxyde@REDACTED Mon Oct 21 13:31:08 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 21 Oct 2013 13:31:08 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <52650C85.50207@ninenines.eu> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> Message-ID: I was not against pull requests in the beginning because I had gathered that whether patches were discussed on GitHub or the mailing-list was at the submitter convenience. But then every time I submitted a patch, a pull request was created for it. I don't care about pull requests for typos, but that's all they should be used for. -- Anthony Ramine Le 21 oct. 2013 ? 13:14, Lo?c Hoguin a ?crit : > They also are useful for very small patches, like fixing typos, because those can be fixed directly using the Github UI, which is a lot more convenient and actually makes these contributions doable, as few people would go all the way to send them otherwise unless they were already setup for contributing. From bayinamine@REDACTED Mon Oct 21 14:09:40 2013 From: bayinamine@REDACTED (Michael Scofield) Date: Mon, 21 Oct 2013 20:09:40 +0800 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? Message-ID: <52651984.6000507@gmail.com> Hi all! I'm new to erlang for a few month. Recently I've developed a small pure erlang program, and it runs well in the shell. Now I want to run it in the background, as a daemon service process in the os (mine is Ubuntu 12.04 64bit with R16B). So I googled "run erlang without shell", and google gave me some advice: 1. Using escript. -This is what erlang official faq suggested ( http://www.erlang.org/faq/how_do_i.html). 2. erl -detached -s Module Function Args I tried both. As to #1, my escript goes to #!/usr/bin/env escript main(_) -> my_supervisor:start_link(arg1, arg2). I ran it using "nohup ./my-escript &", and it didn't run my code. =( So I went to #2. I was acknowledged that "-s" can only pass 0 or 1 argument, so I wrapped my supervisor using -module(run). -export([start/0]). start() -> my_supervisor:start_link(arg1, arg2). and ran my code as "erl -detached -s run start". But this was also a dead end. I guessed it's because the run:start/0 just returned and finished the shell(Is it?), so I added a line to the run:start/0: -module(run). -export([start/0]). start() -> my_supervisor:start_link(arg1, arg2), *receive after infinity -> stop end.* And executed "erl -detached -s run start", and everything goes fine! my_supervisor started to work without the shell! Though the problem "solved", I'm very very confused. 1. Why the "magic line" solved my problem? 2. What exactly is the proper or right way to run an erlang application in the background as the command "nohup ... &" does? Thanks in advance! Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Oct 21 15:38:59 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 21 Oct 2013 17:38:59 +0400 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: <52651984.6000507@gmail.com> References: <52651984.6000507@gmail.com> Message-ID: erl -detached is ok except several problems: 1) if you have any problems with communication with node, it is very hard to stop it. If you kill epmd, you will have big problems with shutting down node. 2) if you have some problems with startup that doesn't allow to start node (common problem: you connect to database in main application supervisor and everything just dies on start), you will not be able to find any debug logs about it. So sometimes you need to use run_erl and to_erl to launch and connect to flussonic. But beware tricky run_erl behaviour. It uses fsync to record on disk every single line of output. So with run_erl you need to lower console debug level to something like "very important" or even "critical" depending on the logger you are using. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon@REDACTED Mon Oct 21 15:49:28 2013 From: jon@REDACTED (Jon Schneider) Date: Mon, 21 Oct 2013 14:49:28 +0100 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: <52651984.6000507@gmail.com> References: <52651984.6000507@gmail.com> Message-ID: It's not a recommended method by I run erl inside a (GNU) screen session. It'll then (normally) automatically detach if you do. Suggest you increase the scrollback history. (Assuming GNU screen it's $HOME/.screenrc with defscrollback largenumber) Jon From daniel.goertzen@REDACTED Mon Oct 21 15:52:03 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 21 Oct 2013 08:52:03 -0500 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: <52651984.6000507@gmail.com> References: <52651984.6000507@gmail.com> Message-ID: A few choices: 1. Take a look at the run_erl and to_erl programs included with Erlang. 2. If you are building your system with rebar, it adds a nice management script for you. 3. Consider running erlang in a tmux or screen window. You'll need to learn a bit about tmux/screen first ... I recommend this ( http://blog.hawkhost.com/tag/tmux-tutorial/) # tmux new-session -d \; new-window 'erl -s run start' # tmux attach Cheers, Dan. On Mon, Oct 21, 2013 at 7:09 AM, Michael Scofield wrote: > Hi all! I'm new to erlang for a few month. > > Recently I've developed a small pure erlang program, and it runs well in > the shell. Now I want to run it in the background, as a daemon service > process in the os (mine is Ubuntu 12.04 64bit with R16B). So I googled "run > erlang without shell", and google gave me some advice: > > 1. Using escript. -This is what erlang official faq suggested ( > http://www.erlang.org/faq/how_do_i.html). > 2. erl -detached -s Module Function Args > > I tried both. As to #1, my escript goes to > > #!/usr/bin/env escript > main(_) -> > my_supervisor:start_link(arg1, arg2). > > I ran it using "nohup ./my-escript &", and it didn't run my code. =( > > So I went to #2. I was acknowledged that "-s" can only pass 0 or 1 > argument, so I wrapped my supervisor using > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2). > > and ran my code as "erl -detached -s run start". But this was also a dead > end. > > I guessed it's because the run:start/0 just returned and finished the > shell(Is it?), so I added a line to the run:start/0: > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2), > *receive after infinity -> stop end.* > > And executed "erl -detached -s run start", and everything goes fine! > my_supervisor started to work without the shell! > > Though the problem "solved", I'm very very confused. > 1. Why the "magic line" solved my problem? > 2. What exactly is the proper or right way to run an erlang application in > the background as the command "nohup ... &" does? > > Thanks in advance! > > Michael > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Oct 21 15:56:05 2013 From: ivan@REDACTED (Ivan uemlianin) Date: Mon, 21 Oct 2013 14:56:05 +0100 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: <52651984.6000507@gmail.com> References: <52651984.6000507@gmail.com> Message-ID: You could always package the program as a release & use the start/stop commands. Might be overkill but does also give you console & attach. Ivan -- festina lente On 21 Oct 2013, at 13:09, Michael Scofield wrote: > Hi all! I'm new to erlang for a few month. > > Recently I've developed a small pure erlang program, and it runs well in the shell. Now I want to run it in the background, as a daemon service process in the os (mine is Ubuntu 12.04 64bit with R16B). So I googled "run erlang without shell", and google gave me some advice: > > 1. Using escript. -This is what erlang official faq suggested ( http://www.erlang.org/faq/how_do_i.html). > 2. erl -detached -s Module Function Args > > I tried both. As to #1, my escript goes to > > #!/usr/bin/env escript > main(_) -> > my_supervisor:start_link(arg1, arg2). > > I ran it using "nohup ./my-escript &", and it didn't run my code. =( > > So I went to #2. I was acknowledged that "-s" can only pass 0 or 1 argument, so I wrapped my supervisor using > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2). > > and ran my code as "erl -detached -s run start". But this was also a dead end. > > I guessed it's because the run:start/0 just returned and finished the shell(Is it?), so I added a line to the run:start/0: > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2), > receive after infinity -> stop end. > > And executed "erl -detached -s run start", and everything goes fine! my_supervisor started to work without the shell! > > Though the problem "solved", I'm very very confused. > 1. Why the "magic line" solved my problem? > 2. What exactly is the proper or right way to run an erlang application in the background as the command "nohup ... &" does? > > Thanks in advance! > > Michael > _______________________________________________ > 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 Mon Oct 21 15:57:19 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 21 Oct 2013 17:57:19 +0400 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: References: <52651984.6000507@gmail.com> Message-ID: release doesn't do any magic. It is just to_erl and run_erl programs with some wrapping. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Oct 21 15:58:19 2013 From: ivan@REDACTED (Ivan uemlianin) Date: Mon, 21 Oct 2013 14:58:19 +0100 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: <52651984.6000507@gmail.com> References: <52651984.6000507@gmail.com> Message-ID: <4BDFF596-91DB-4BE5-BEC7-AE66FA11A9D2@llaisdy.com> ... having said that, I do have a little erlang program I run as an escript in a tmux session. Ivan -- festina lente On 21 Oct 2013, at 13:09, Michael Scofield wrote: > Hi all! I'm new to erlang for a few month. > > Recently I've developed a small pure erlang program, and it runs well in the shell. Now I want to run it in the background, as a daemon service process in the os (mine is Ubuntu 12.04 64bit with R16B). So I googled "run erlang without shell", and google gave me some advice: > > 1. Using escript. -This is what erlang official faq suggested ( http://www.erlang.org/faq/how_do_i.html). > 2. erl -detached -s Module Function Args > > I tried both. As to #1, my escript goes to > > #!/usr/bin/env escript > main(_) -> > my_supervisor:start_link(arg1, arg2). > > I ran it using "nohup ./my-escript &", and it didn't run my code. =( > > So I went to #2. I was acknowledged that "-s" can only pass 0 or 1 argument, so I wrapped my supervisor using > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2). > > and ran my code as "erl -detached -s run start". But this was also a dead end. > > I guessed it's because the run:start/0 just returned and finished the shell(Is it?), so I added a line to the run:start/0: > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2), > receive after infinity -> stop end. > > And executed "erl -detached -s run start", and everything goes fine! my_supervisor started to work without the shell! > > Though the problem "solved", I'm very very confused. > 1. Why the "magic line" solved my problem? > 2. What exactly is the proper or right way to run an erlang application in the background as the command "nohup ... &" does? > > Thanks in advance! > > Michael > _______________________________________________ > 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 Oct 21 17:13:21 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 21 Oct 2013 11:13:21 -0400 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> Message-ID: <20131021151320.GF5671@ferdair.local> It sounds to me that what would be pretty nice to have is the ability to set comments to be uneditable in github, preserve their history, or at the very least show that they were amended. It is a fixable problem. I agree on the openness of the protocol, but I'm wondering if the OTP team is seeing more contributions now that pull requests are accepted from the github web site. The one true objective of pull requests or mailing lists is to let the community contribute. If the community contributes more through pull requests than the mailing list, then we have to consider which of the objectives between the total amount of contributions or the principles behind the technology used are what is to be prioritized there. You can't beat mailing lists' openness, but you may beat their user base. This is to be confirmed, however. Regards, Fred. On 10/21, Anthony Ramine wrote: > Hello, > > I don't like the switch to GitHub pull requests and I argued about it in a nondescript pull request that was made for one of my patches. > > I could just link to it [1] but as there is no guarantee about comments in GitHub's system, I will copy and paste what I wrote there: > > > Otherwise while pull requests are good in theory, @OTP-Maintainer gives a good example of where it sucks big time, you have to take care of formatting your emails etc, and Markdown is underspecified. I would rather have plain text emails which I can browse offline. I don't even have my own comments received by email when using pull requests, that's splitting information. > > > > We gave up on standard email protocols to use a proprietary forum, this sucks. > > > > Also, while someone can't delete an email that I have already received, anyone can delete a comment he made on GitHub. I fail to see that as an improvement. > > > > And people can also amend their comments whenever they want, this is insane. > > > Please do not try to make me believe that amending of comments is harmless and won't be a reality. When I look at the amount of aggressivity that is shown around here sometimes, I can't even begin to fathom what can happen when discussion can be altered after the fact at any given point in time. > > Please don't tell me either that learning Markdown is easy. Just take a look at big profile repositories like the OS X package manager Homebrew: most bug reports and build logs are never properly formatted and you end up with unusable garbage where even squinting your eyes won't help. Nobody care about properly formatting comments. > > You can't beat mailing-lists' openness. > > Regards, > > [1] https://github.com/erlang/otp/pull/103#issuecomment-26706198 > > -- > Anthony Ramine > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From serge@REDACTED Mon Oct 21 17:56:43 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 21 Oct 2013 11:56:43 -0400 Subject: [erlang-questions] Distributed Erlang transport over SSL Message-ID: Is it possible to have SSL distributed transport enabled to connect to selective nodes without a requirement to run SSL in the whole cluster? We have a configuration with N local nodes, and a handful of remote nodes, where connectivity to remote nodes is done over Internet, and would like only those connections to use SSL. While the http://www.erlang.org/doc/apps/ssl/ssl_distribution.html chapter describes in detail how to run a node with SSL support, but there's doesn't seem to be any documentation of if it's possible to give hints to a given node to use transport alternative to the one used by current node at startup when connecting to given nodes. If this is not supported, I would opt for this feature request as this seems to be a very general case when running node configurations spanning multiple clusters. Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Mon Oct 21 18:28:33 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 21 Oct 2013 18:28:33 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> Message-ID: <52655631.3060909@erlang.org> On 2013-10-21 13:31, Anthony Ramine wrote: > I was not against pull requests in the beginning because I had gathered that whether patches were discussed on GitHub or the mailing-list was at the submitter convenience. But then every time I submitted a patch, a pull request was created for it. Just to say why we create pull requests for most (all?) patches nowadays. We create them because the changes are then easily put into our review system and we can actually keep track of them. With the ML's the patches can get lost in the signal/noise ratio. We at OTP don't use GitHub for bug-tracking, we merely use GH as a conduit to you, the community, and it seemed like the most effective tool for us to do this. We can also automate certain things for it, like doc and build testing. Saves time. > I don't care about pull requests for typos, but that's all they should be used for. My thoughts on this. I will certianly agree with you that GH has shortcomings. Especially with issue tracking but also with pull requests (to a lesser degree). I don't think we will ever use the issue tracking on GH as it is just plain awful for larger projects but it might be suitable for other things, like community driven tasks. I don't share your concern that the history of a pull requsts can change or gets lost (deleted). I mean, I do belive this might happen but the information in a PR should translate to an OTP-ticket and all the relevant information should be either in the commit message or the ticket (or both). I view PR and ML information as transient data to forward the work of the patch. The relevant information should be in the commit message when final. But I've certianly been the there. Pondering "what were they thinking" when reviewing legacy code. In Git, this information should be in the commit message .. not in a mail discussion (or in a PR). So if anything, we should be even harder on clear and informative commit messages. I think we should give GitHub a little more time. I think pull requests is a nice addition as it saves time for us. ML's are just awful in this regard. I don't think we have found the optimal ways of working with GitHub, ML's and patches yet. We are still learning. As always, your feedback is welcomed! We strive to make this better for all involved. =) // Bj?rn-Egil From desired.mta@REDACTED Mon Oct 21 18:39:24 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Mon, 21 Oct 2013 18:39:24 +0200 Subject: [erlang-questions] Distributed Erlang transport over SSL In-Reply-To: References: Message-ID: On Mon, Oct 21, 2013 at 5:56 PM, Serge Aleynikov wrote: > seem to be any documentation of if it's possible to give hints to a given > node to use transport alternative to the one used by current node at startup > when connecting to given nodes. > > If this is not supported, I would opt for this feature request as this seems > to be a very general case when running node configurations spanning multiple > clusters. Hi, See Patrick Nyblon's reply to a similar question: http://erlang.org/pipermail/erlang-questions/2012-October/069876.html >From the last paragraph I infer that what you are trying to do is supported or easily supportable (lacks details though). -- Motiejus Jak?tys From anthonym@REDACTED Mon Oct 21 18:42:06 2013 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Mon, 21 Oct 2013 09:42:06 -0700 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <52655631.3060909@erlang.org> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> Message-ID: <22D3D20B-27ED-4478-ABEE-ACD47EA140B9@alumni.caltech.edu> Hi, I am certain the folks at github would love feedback on their system. It seems like Fred's idea of uneditable comments would be something they might consider as a repository specific control. I'd recommend sending them an email with suggestions. -Anthony On Oct 21, 2013, at 9:28 AM, Bj?rn-Egil Dahlberg wrote: > On 2013-10-21 13:31, Anthony Ramine wrote: >> I was not against pull requests in the beginning because I had gathered that whether patches were discussed on GitHub or the mailing-list was at the submitter convenience. But then every time I submitted a patch, a pull request was created for it. > Just to say why we create pull requests for most (all?) patches nowadays. > > We create them because the changes are then easily put into our review system and we can actually keep track of them. With the ML's the patches can get lost in the signal/noise ratio. > > We at OTP don't use GitHub for bug-tracking, we merely use GH as a conduit to you, the community, and it seemed like the most effective tool for us to do this. We can also automate certain things for it, like doc and build testing. Saves time. > >> I don't care about pull requests for typos, but that's all they should be used for. > My thoughts on this. > > I will certianly agree with you that GH has shortcomings. Especially with issue tracking but also with pull requests (to a lesser degree). I don't think we will ever use the issue tracking on GH as it is just plain awful for larger projects but it might be suitable for other things, like community driven tasks. > > I don't share your concern that the history of a pull requsts can change or gets lost (deleted). I mean, I do belive this might happen but the information in a PR should translate to an OTP-ticket and all the relevant information should be either in the commit message or the ticket (or both). I view PR and ML information as transient data to forward the work of the patch. The relevant information should be in the commit message when final. > > But I've certianly been the there. Pondering "what were they thinking" when reviewing legacy code. In Git, this information should be in the commit message .. not in a mail discussion (or in a PR). So if anything, we should be even harder on clear and informative commit messages. > > I think we should give GitHub a little more time. I think pull requests is a nice addition as it saves time for us. ML's are just awful in this regard. I don't think we have found the optimal ways of working with GitHub, ML's and patches yet. We are still learning. > > As always, your feedback is welcomed! We strive to make this better for all involved. =) > > // Bj?rn-Egil > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tuncer.ayaz@REDACTED Mon Oct 21 20:04:01 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 21 Oct 2013 20:04:01 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <52655631.3060909@erlang.org> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> Message-ID: On Mon, Oct 21, 2013 at 6:28 PM, Bjorn-Egil Dahlberg wrote: > On 2013-10-21 13:31, Anthony Ramine wrote: >> >> I was not against pull requests in the beginning because I had >> gathered that whether patches were discussed on GitHub or the >> mailing-list was at the submitter convenience. But then every time >> I submitted a patch, a pull request was created for it. > > Just to say why we create pull requests for most (all?) patches > nowadays. Should we skip sending mails to erlang-patches@ from now on? > We create them because the changes are then easily put into our > review system and we can actually keep track of them. With the ML's > the patches can get lost in the signal/noise ratio. > > We at OTP don't use GitHub for bug-tracking, we merely use GH as a > conduit to you, the community, and it seemed like the most effective > tool for us to do this. We can also automate certain things for it, > like doc and build testing. Saves time. Given the use of pull requests for otp.git, what about automatically syncing bugs to/from https://github.com/erlang/otp/issues? >> I don't care about pull requests for typos, but that's all they >> should be used for. > > My thoughts on this. > > I will certianly agree with you that GH has shortcomings. Especially > with issue tracking but also with pull requests (to a lesser > degree). I don't think we will ever use the issue tracking on GH as > it is just plain awful for larger projects but it might be suitable > for other things, like community driven tasks. > > I don't share your concern that the history of a pull requsts can > change or gets lost (deleted). I mean, I do belive this might happen I think Anthony is right, and using the patch-queue approach of a cleanly rebased branch, code comments can also disappear. I haven't figured out the pattern yet, but sometimes after a rebase old comments are still linked but collapsed, and sometimes they're gone. I prefer Gerrit's code review functionality for this particularly feature. Also, the way github inserts new commits into the discussion is debatable. > but the information in a PR should translate to an OTP-ticket and > all the relevant information should be either in the commit message > or the ticket (or both). I view PR and ML information as transient > data to forward the work of the patch. The relevant information > should be in the commit message when final. > > But I've certianly been the there. Pondering "what were they > thinking" when reviewing legacy code. In Git, this information > should be in the commit message .. not in a mail discussion (or in a > PR). So if anything, we should be even harder on clear and > informative commit messages. > > I think we should give GitHub a little more time. I think pull > requests is a nice addition as it saves time for us. ML's are just > awful in this regard. I don't think we have found the optimal ways > of working with GitHub, ML's and patches yet. We are still learning. > > As always, your feedback is welcomed! We strive to make this better > for all involved. =) From tuncer.ayaz@REDACTED Mon Oct 21 20:06:23 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 21 Oct 2013 20:06:23 +0200 Subject: [erlang-questions] compile: making asm and core official In-Reply-To: References: Message-ID: On Fri, Aug 23, 2013 at 2:13 PM, Tuncer Ayaz wrote: > Motivated by a discussion at https://github.com/rebar/rebar/issues/105 > and Bjorn-Egil's suggestion, I'd like to ask for opinions on > officially supporting 'core' and 'asm' as compile:file/2 options. > > (1) How likely are you to accept patches which would: > > * Implement support for compile:file(File, [core]) same as > compile:file(File, [asm]). > > * Officially document 'core' and 'asm' as external names for > 'from_asm' and 'from_core'? > > * Change the existing documentation for 'asm' to not discourage use of > the option as much. > > * Officially document that "erlc foo.core" and "erlc foo.S" have been > wired to from_core and from_asm for ages? > > (2) Document compile_core/3 and compile_asm/3 > > Alternatively, one could call compile:compile_asm/3 and > compile:compile_core/3, but they're internal functions meant to be > used only from erl_compile (used by erlc). This would actually be the > most backwards compatible solution if we don't want to require a > patched compile.beam. > > So, what about alternatively or additionally documenting > compile_core/3 and compile_asm/3? ping From tuncer.ayaz@REDACTED Mon Oct 21 20:18:15 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 21 Oct 2013 20:18:15 +0200 Subject: [erlang-questions] reltool: sys-level {mod_cond, derived} In-Reply-To: References: Message-ID: On Mon, Apr 15, 2013 at 11:49 AM, Siri Hansen wrote: > I think this only reflects the application dependencies as they > actually look > > sasl uses tools > tools uses webtool (cover) and inets > webtool uses observer > inets uses mnesia, runtime_tools, ssl, > observer uses gs, wx, et > ssl uses crypto and public_key > ... > > Adding {mod_cond,derived} is the way to limit the way reltool > calculates the application dependencies. AFAIU, reltool has the relevant information at runtime and could warn about missing deps or derive the deps even when {mod_cond,derived} is set. Isn't that the most reasonable behavior? Or is there a distinction between hard and soft mod deps? > Regards > /siri > > 2013/4/6 Tuncer Ayaz >> >> As discussed previously[1] it was decided to make the default >> rebar reltool.config template safer to use by removing[2] the >> non-default sys-level mod_cond. >> >> While this doesn't produce releases with potentially missing >> modules, that one-line patch also pulls in many seemingly unused >> applications resulting in a release that's at least twice as big: >> >> With sys-level {mod_cond, derived} (aka non-default settings): >> $ ls -1 rel/exemplar/lib >> compiler-4.9.1 >> crypto-2.3 >> erts-5.10.1 >> exemplar >> hipe-3.10.1 >> kernel-2.16.1 >> sasl-2.3.1 >> stdlib-1.19.1 >> tools-2.6.10 >> >> Without sys-level {mod_cond, derived} (aka default settings): >> $ g diff >> diff --git a/rel/reltool.config b/rel/reltool.config >> index 2dd47be..e65c53c 100644 >> --- a/rel/reltool.config >> +++ b/rel/reltool.config >> @@ -19,7 +19,6 @@ >> {boot_rel, "exemplar"}, >> {profile, embedded}, >> {incl_cond, derived}, >> - {mod_cond, derived}, >> {excl_archive_filters, [".*"]}, %% Do not archive built libs >> {excl_sys_filters, ["^bin/.*", "^erts.*/bin/(dialyzer|typer)", >> "^erts.*/(doc|info|include|lib|man|src)"]}, >> >> $ ls -1 rel/exemplar/lib >> asn1-2.0.1 >> compiler-4.9.1 >> crypto-2.3 >> edoc-0.7.12 >> erts-5.10.1 >> et-1.4.4.3 >> exemplar >> gs-1.5.15.2 >> hipe-3.10.1 >> inets-5.9.4 >> kernel-2.16.1 >> mnesia-4.8 >> observer-1.3 >> public_key-0.18 >> runtime_tools-1.8.10 >> sasl-2.3.1 >> ssl-5.2.1 >> stdlib-1.19.1 >> syntax_tools-1.6.11 >> tools-2.6.10 >> webtool-0.8.9.2 >> wx-1.0 >> xmerl-1.3.3 >> >> To reproduce, follow the steps found in >> https://github.com/rebar/rebar/wiki/Release-handling >> and make sure to delete the sys-level mod_cond. >> >> If you want to keep the sys-level {mod_cond, derived} and use the >> nodetool escript, remember to add the following line: >> {app, compiler, [{mod_cond, app}]}, >> Otherwise reltool might not include[3] some compiler modules which are >> used due to the `-mode(compile)` directive. As I don't think the >> nodetool escript has anything to gain by being compiled, I've posted a >> patch to delete[4] the directive. >> >> So, the question is, is this expected reltool behaviour? If so, is >> this really desired or not possibly including much more than is >> actually used. Shouldn't the sys-level {incl_cond, derived} make >> sure only used applications are included (regardless of mod_cond)? >> >> [1] http://erlang.org/pipermail/erlang-questions/2012-December/071135.html >> [2] https://github.com/rebar/rebar/pull/43 >> [3] https://github.com/rebar/rebar/issues/64#issuecomment-15998750 >> [4] https://github.com/rebar/rebar/pull/80 From wbin00@REDACTED Tue Oct 22 04:37:28 2013 From: wbin00@REDACTED (Bin Wang) Date: Tue, 22 Oct 2013 10:37:28 +0800 Subject: [erlang-questions] Question about gen_fsm timeout Message-ID: There is an locked door example aboout gen_fsm in the Elrang Otp System Documentation. I have a question about timeout. I will copy the code here first: -module(code_lock). -behaviour(gen_fsm). -export([start_link/1]). -export([button/1]). -export([init/1, locked/2, open/2]). start_link(Code) -> gen_fsm:start_link({local, code_lock}, code_lock, lists:reverse(Code, []). button(Digit) -> gen_fsm:send_event(code_lock, {button, Digit}). init(Code) -> {ok, locked, {[], Code}}. locked({button, Digit}, {SoFar, Code}) -> case [Digit|SoFar] of Code -> do_unlock(), {next_state, open, {[], Code}, 30000}; Incomplete when length(Incomplete) {next_state, locked, {Incomplete, Code}}; _Wrong -> {next_state, locked, {[], Code}} end. open(timeout, State) -> do_lock(), {next_state, locked, State}. Here is the question: when the door is opened, if I press the button, the gen_fsm will have an {button, Digit} event at the state open. An error will occurs. But if I add these code after open function: open(_Event, State) -> {next_state, open, State}. Then if I press the button in 30s, the timeout will not be occurs. The door will open forever. What should I do? Thanks. --- Bin Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbobroff@REDACTED Tue Oct 22 05:02:53 2013 From: sbobroff@REDACTED (Sam Bobroff) Date: Tue, 22 Oct 2013 03:02:53 +0000 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: <52651984.6000507@gmail.com> References: <52651984.6000507@gmail.com> Message-ID: <3D949925692E3A429DEFDEECDA1DDB91A1060CB5@SVLITMX02.shoretel.com> There is also a third-party tool, erld, that helps with running Erlang as a well behaved unix daemon. (Disclaimer: I'm the author.) It's described here: https://github.com/ShoreTel-Inc/erld/wiki Cheers, Sam. On 21/10/2013, at 11:09 PM, Michael Scofield > wrote: Hi all! I'm new to erlang for a few month. Recently I've developed a small pure erlang program, and it runs well in the shell. Now I want to run it in the background, as a daemon service process in the os (mine is Ubuntu 12.04 64bit with R16B). So I googled "run erlang without shell", and google gave me some advice: 1. Using escript. -This is what erlang official faq suggested ( http://www.erlang.org/faq/how_do_i.html). 2. erl -detached -s Module Function Args I tried both. As to #1, my escript goes to #!/usr/bin/env escript main(_) -> my_supervisor:start_link(arg1, arg2). I ran it using "nohup ./my-escript &", and it didn't run my code. =( So I went to #2. I was acknowledged that "-s" can only pass 0 or 1 argument, so I wrapped my supervisor using -module(run). -export([start/0]). start() -> my_supervisor:start_link(arg1, arg2). and ran my code as "erl -detached -s run start". But this was also a dead end. I guessed it's because the run:start/0 just returned and finished the shell(Is it?), so I added a line to the run:start/0: -module(run). -export([start/0]). start() -> my_supervisor:start_link(arg1, arg2), receive after infinity -> stop end. And executed "erl -detached -s run start", and everything goes fine! my_supervisor started to work without the shell! Though the problem "solved", I'm very very confused. 1. Why the "magic line" solved my problem? 2. What exactly is the proper or right way to run an erlang application in the background as the command "nohup ... &" does? Thanks in advance! Michael _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Tue Oct 22 06:53:56 2013 From: james@REDACTED (James Aimonetti) Date: Mon, 21 Oct 2013 21:53:56 -0700 Subject: [erlang-questions] Question about gen_fsm timeout In-Reply-To: References: Message-ID: <526604E4.1030909@2600hz.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Perhaps gen_fsm:send_event_after/2 would be useful? http://erldocs.com/R16B02/stdlib/gen_fsm.html#send_event_after/2 On 10/21/2013 07:37 PM, Bin Wang wrote: > There is an locked door example aboout gen_fsm in the Elrang Otp > System Documentation. I have a question about timeout. I will > copy the code here first: > > -module(code_lock). -behaviour(gen_fsm). -export([start_link/1]). > -export([button/1]). -export([init/1, locked/2, open/2]). > > start_link(Code) -> gen_fsm:start_link({local, code_lock}, > code_lock, lists:reverse(Code, []). > > button(Digit) -> gen_fsm:send_event(code_lock, {button, Digit}). > > init(Code) -> {ok, locked, {[], Code}}. > > locked({button, Digit}, {SoFar, Code}) -> case [Digit|SoFar] of > Code -> do_unlock(), {next_state, open, {[], Code}, 30000}; > Incomplete when length(Incomplete) {next_state, > locked, {Incomplete, Code}}; _Wrong -> {next_state, locked, {[], > Code}} end. > > open(timeout, State) -> do_lock(), {next_state, locked, State}. > > Here is the question: when the door is opened, if I press the > button, the gen_fsm will have an {button, Digit} event at the > state open. An error will occurs. But if I add these code after > open function: > > open(_Event, State) -> {next_state, open, State}. > > Then if I press the button in 30s, the timeout will not be occurs. > The door will open forever. What should I do? > > Thanks. > > --- Bin Wang > > > > _______________________________________________ erlang-questions > mailing list erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > - -- James Aimonetti Lead Systems Architect "I thought I fixed that" 2600Hz | http://2600hz.com sip:james@REDACTED tel:415.886.7905 irc:mc_ @ freenode -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlJmBOQACgkQ54NxaUq7OmCp6gD/RrMjVwrLO4QWwh5sAKqj1p4p utwwxG7zUDDvaIFk/fUA/2U9Mj4WRd2Ep3lm+mFSMwRpw46/WO5JtWboTjNlUlc/ =dMGn -----END PGP SIGNATURE----- From shian5@REDACTED Tue Oct 22 06:28:32 2013 From: shian5@REDACTED (Shian Wu) Date: Tue, 22 Oct 2013 12:28:32 +0800 Subject: [erlang-questions] Question about gen_fsm timeout Message-ID: Hi Your return of open(timeout, State) will clean the timeout value. You may change open(timeout, State) -> do_lock(), {next_state, locked, State}. to open(timeout, State) -> do_lock(), {next_state, locked, State}; open(_Event, State) -> {next_state, open, State, 30000}. Another note, timeout will occur unless a request or a message is received. If user keep to click button, it will not able to lock door ;p --- Shian Wu On Tue, Oct 22, 2013 at 10:37 AM, Bin Wang wrote: > There is an locked door example aboout gen_fsm in the Elrang Otp System > Documentation. I have a question about timeout. I will copy the code here > first: > > -module(code_lock). > -behaviour(gen_fsm). > -export([start_link/1]). > -export([button/1]). > -export([init/1, locked/2, open/2]). > > start_link(Code) -> > gen_fsm:start_link({local, code_lock}, code_lock, lists:reverse(Code, > []). > > button(Digit) -> > gen_fsm:send_event(code_lock, {button, Digit}). > > init(Code) -> > {ok, locked, {[], Code}}. > > locked({button, Digit}, {SoFar, Code}) -> > case [Digit|SoFar] of > Code -> > do_unlock(), > {next_state, open, {[], Code}, 30000}; > Incomplete when length(Incomplete) > {next_state, locked, {Incomplete, Code}}; > _Wrong -> > {next_state, locked, {[], Code}} > end. > > open(timeout, State) -> > do_lock(), > {next_state, locked, State}. > > Here is the question: when the door is opened, if I press the button, the > gen_fsm will have an {button, Digit} event at the state open. An error will > occurs. But if I add these code after open function: > > open(_Event, State) -> > {next_state, open, State}. > > Then if I press the button in 30s, the timeout will not be occurs. The > door will open forever. What should I do? > > Thanks. > > --- > Bin Wang > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Oct 22 11:45:04 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 22 Oct 2013 10:45:04 +0100 Subject: [erlang-questions] A (hopefully simple) diameter relay question In-Reply-To: <2AE24381-E107-475E-A7FF-4DD6F901A2EA@gmail.com> References: <8274ED17-5DAC-4BB2-9986-728624578233@btinternet.com> <52611937.6020606@gmail.com> <2AE24381-E107-475E-A7FF-4DD6F901A2EA@gmail.com> Message-ID: Hi Anders, On 10/18/2013 05:45 PM, Anders Svensson wrote: One thing that's not quite right in your configuration is that both the relay and server identify themselves with Origin-Host=service.example.com. The server is another Diameter node that should have its own identity. Not sure if that could be a problem (don't know seagull for one) but it's not impossible. Similarly, the client should also have its own identity. The relay closing the connection upon reception of CEA means that there's something it doesn't like. If you trace on diameter_peer_fsm:terminate/2 then we should be able to see why. I fixed the Origin-Host (on all three peers), and you're right about the relay rejecting the CEA. It looks to me like the upstream (server) is rejecting the CER with a 3xxx error code: (<0.248.0>) call diameter_peer_fsm:terminate({shutdown,{'CEA',{'Wait-CEA',1192247597,1192247597}}},{state, {'Wait-CEA',1192247597,1192247597}, {connect,{{127,0,0,1},3868}}, <0.247.0>,<0.256.0>,diameter_gen_base_rfc3588, {diameter_service,<0.245.0>, {diameter_caps,"relay.example.com","example.com", [{127,0,0,1}], 193,"Server",[],[], [4294967295], [],[],[],[],[]}, [{diameter_app,m_diameter_service,diameter_gen_relay, [m_diameter_relay], m_diameter_service,4294967295,false, [{answer_errors,report},{request_errors,answer_3xxx}]}]}, false,exit}) (<0.248.0>) returned from diameter_peer_fsm:terminate/2 -> ok (<0.278.0>) call diameter_peer_fsm:terminate({shutdown,{'CEA',timeout}},{state, {'Wait-CEA',1192247598,1192247598}, {connect,{{127,0,0,1},3868}}, <0.247.0>,<0.279.0>,diameter_gen_base_rfc3588, {diameter_service,<0.245.0>, {diameter_caps,"relay.example.com","example.com", [{127,0,0,1}], 193,"Server",[],[], [4294967295], [],[],[],[],[]}, [{diameter_app,m_diameter_service,diameter_gen_relay, [m_diameter_relay], m_diameter_service,4294967295,false, [{answer_errors,report},{request_errors,answer_3xxx}]}]}, false,exit}) (<0.278.0>) returned from diameter_peer_fsm:terminate/2 -> ok (<0.285.0>) call diameter_peer_fsm:terminate({shutdown,{'CEA',timeout}},{state, {'Wait-CEA',1192247599,1192247599}, {connect,{{127,0,0,1},3868}}, <0.247.0>,<0.286.0>,diameter_gen_base_rfc3588, {diameter_service,<0.245.0>, {diameter_caps,"relay.example.com","example.com", [{127,0,0,1}], 193,"Server",[],[], [4294967295], [],[],[],[],[]}, [{diameter_app,m_diameter_service,diameter_gen_relay, [m_diameter_relay], m_diameter_service,4294967295,false, [{answer_errors,report},{request_errors,answer_3xxx}]}]}, false,exit}) (<0.285.0>) returned from diameter_peer_fsm:terminate/2 -> ok I'll take a look at the test server configuration and see if I can figure out why. Thanks for the assist here - I'll try and remember to let the list know how I resolve this, for the benefit of future readers. Cheers, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 22 12:01:59 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 22 Oct 2013 12:01:59 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <52655631.3060909@erlang.org> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> Message-ID: <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> Replied inline. -- Anthony Ramine Le 21 oct. 2013 ? 18:28, Bj?rn-Egil Dahlberg a ?crit : > Just to say why we create pull requests for most (all?) patches nowadays. I understand that, but why force people who prefer the mailing-list to comment on GitHub? > We create them because the changes are then easily put into our review system and we can actually keep track of them. With the ML's the patches can get lost in the signal/noise ratio. I don't see how patches can get lost on erlang-patches, it's not like bugs, questions and patches end up in the same place. > We at OTP don't use GitHub for bug-tracking, we merely use GH as a conduit to you, the community, and it seemed like the most effective tool for us to do this. We can also automate certain things for it, like doc and build testing. Saves time. Couldn't you improve your internal bug-tracking to expose some parts of it to the public? That would certainly make things more future proof. > I don't share your concern that the history of a pull requsts can change or gets lost (deleted). I mean, I do belive this might happen but the information in a PR should translate to an OTP-ticket and all the relevant information should be either in the commit message or the ticket (or both). I view PR and ML information as transient data to forward the work of the patch. The relevant information should be in the commit message when final. I can download the whole erlang-patches archives, I have already found interesting stuff in it. When we switch off GitHub in a few years, this won't be doable for everything that will have happened meanwhile. > But I've certianly been the there. Pondering "what were they thinking" when reviewing legacy code. In Git, this information should be in the commit message .. not in a mail discussion (or in a PR). So if anything, we should be even harder on clear and informative commit messages. That's an ideal, but reality says otherwise. Especially so for rejected patches where there is no commit, by definition (e.g. the previous attempts to fix the =<< situation). > I think we should give GitHub a little more time. I think pull requests is a nice addition as it saves time for us. ML's are just awful in this regard. I don't think we have found the optimal ways of working with GitHub, ML's and patches yet. We are still learning. The initial point of supporting GitHub's PRs was to make the work easier for the community, not the OTP team. From letien83@REDACTED Tue Oct 22 11:29:55 2013 From: letien83@REDACTED (Tien Le) Date: Tue, 22 Oct 2013 11:29:55 +0200 Subject: [erlang-questions] Synchronous way to handle timeout between gen_server(s) Message-ID: Hi, Please look at my sample code below. I have 2 gen_servers (serv1 and serv2). serv1 start_link serv2, and traps exit. %%% serv1:do/0 implementation: %%% do() -> gen_server:call(serv1, do). handle_call(do, _From, State) -> Result = serv2:do(), {reply, Result, State}. %%% serv2:do/0 implementation: %%% do() -> gen_server:call(serv2, do). handle_call(do, _From, State) -> %% Something that takes time like timer:sleep/1 Result = timer:sleep(5000), {reply, Result, State}. As you can see that serv1's gen_server:call and serv2's gen_server:call have the same timeout value (5000ms by default). When I call serv1:do(). serv1 always terminates first due to timed out: =CRASH REPORT==== 22-Oct-2013::10:26:38 === crasher: initial call: serv1:init/1 pid: <0.43.0> registered_name: serv1 exception exit: {timeout,{gen_server,call,[serv2,do]}} in function gen_server:terminate/6 (gen_server.erl, line 747) ... One workaround is to increase the timeout of serv1 and serv2 gen_server:call/3, like this: gen_server:call(serv1, do, *5020*) => gen_server:call(serv2, do, *5010*) => timer:sleep(*5000*) I would like to ask you if there's any nicer and synchronous way to handle the timeout in this case? -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Tue Oct 22 12:46:17 2013 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 22 Oct 2013 12:46:17 +0200 Subject: [erlang-questions] Synchronous way to handle timeout between gen_server(s) In-Reply-To: References: Message-ID: Hello! Exactly what would you like to achieve? If you don't expect serv2 to freeze, you can set the timeouts in the gen_server:calls to infinity. 2013/10/22 Tien Le : > Hi, > > Please look at my sample code below. I have 2 gen_servers (serv1 and serv2). > serv1 start_link serv2, and traps exit. > > %%% serv1:do/0 implementation: %%% > do() -> > gen_server:call(serv1, do). > > handle_call(do, _From, State) -> > Result = serv2:do(), > {reply, Result, State}. > > > %%% serv2:do/0 implementation: %%% > do() -> > gen_server:call(serv2, do). > > handle_call(do, _From, State) -> > %% Something that takes time like timer:sleep/1 > Result = timer:sleep(5000), > {reply, Result, State}. > > > As you can see that serv1's gen_server:call and serv2's gen_server:call have > the same timeout value (5000ms by default). > > When I call serv1:do(). > serv1 always terminates first due to timed out: > > =CRASH REPORT==== 22-Oct-2013::10:26:38 === > crasher: > initial call: serv1:init/1 > pid: <0.43.0> > registered_name: serv1 > exception exit: {timeout,{gen_server,call,[serv2,do]}} > in function gen_server:terminate/6 (gen_server.erl, line 747) > ... > > One workaround is to increase the timeout of serv1 and serv2 > gen_server:call/3, like this: > gen_server:call(serv1, do, 5020) => gen_server:call(serv2, do, 5010) => > timer:sleep(5000) > > I would like to ask you if there's any nicer and synchronous way to handle > the timeout in this case? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From arun11299@REDACTED Tue Oct 22 13:22:22 2013 From: arun11299@REDACTED (Arun Muralidharan) Date: Tue, 22 Oct 2013 16:52:22 +0530 Subject: [erlang-questions] Synchronous way to handle timeout between gen_server(s) In-Reply-To: References: Message-ID: Not 100% sure, but you can catch the timeout with handle_info. Somethig like handle_info(timeout, State)-> # do something . -Arun On Tue, Oct 22, 2013 at 4:16 PM, Attila Rajmund Nohl < attila.r.nohl@REDACTED> wrote: > Hello! > > Exactly what would you like to achieve? If you don't expect serv2 to > freeze, you can set the timeouts in the gen_server:calls to infinity. > > 2013/10/22 Tien Le : > > Hi, > > > > Please look at my sample code below. I have 2 gen_servers (serv1 and > serv2). > > serv1 start_link serv2, and traps exit. > > > > %%% serv1:do/0 implementation: %%% > > do() -> > > gen_server:call(serv1, do). > > > > handle_call(do, _From, State) -> > > Result = serv2:do(), > > {reply, Result, State}. > > > > > > %%% serv2:do/0 implementation: %%% > > do() -> > > gen_server:call(serv2, do). > > > > handle_call(do, _From, State) -> > > %% Something that takes time like timer:sleep/1 > > Result = timer:sleep(5000), > > {reply, Result, State}. > > > > > > As you can see that serv1's gen_server:call and serv2's gen_server:call > have > > the same timeout value (5000ms by default). > > > > When I call serv1:do(). > > serv1 always terminates first due to timed out: > > > > =CRASH REPORT==== 22-Oct-2013::10:26:38 === > > crasher: > > initial call: serv1:init/1 > > pid: <0.43.0> > > registered_name: serv1 > > exception exit: {timeout,{gen_server,call,[serv2,do]}} > > in function gen_server:terminate/6 (gen_server.erl, line 747) > > ... > > > > One workaround is to increase the timeout of serv1 and serv2 > > gen_server:call/3, like this: > > gen_server:call(serv1, do, 5020) => gen_server:call(serv2, do, 5010) => > > timer:sleep(5000) > > > > I would like to ask you if there's any nicer and synchronous way to > handle > > the timeout in this case? > > > > > > > > _______________________________________________ > > 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 serge@REDACTED Tue Oct 22 13:47:05 2013 From: serge@REDACTED (Serge Aleynikov) Date: Tue, 22 Oct 2013 07:47:05 -0400 Subject: [erlang-questions] Distributed Erlang transport over SSL In-Reply-To: References: Message-ID: Thanks! I'll experiment with this. Meanwhile, if anyone had experience with running a similar non-heterogeneous SSL/tcp internode transport setup and could share details, that would be very helpful. On Mon, Oct 21, 2013 at 12:39 PM, Motiejus Jak?tys wrote: > On Mon, Oct 21, 2013 at 5:56 PM, Serge Aleynikov > wrote: > > seem to be any documentation of if it's possible to give hints to a given > > node to use transport alternative to the one used by current node at > startup > > when connecting to given nodes. > > > > If this is not supported, I would opt for this feature request as this > seems > > to be a very general case when running node configurations spanning > multiple > > clusters. > > Hi, > > See Patrick Nyblon's reply to a similar question: > http://erlang.org/pipermail/erlang-questions/2012-October/069876.html > > From the last paragraph I infer that what you are trying to do is > supported or easily supportable (lacks details though). > > -- > Motiejus Jak?tys > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Oct 22 13:54:28 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 22 Oct 2013 13:54:28 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> Message-ID: <52666774.4030203@erlang.org> On 2013-10-22 12:01, Anthony Ramine wrote: >> Just to say why we create pull requests for most (all?) patches nowadays. > I understand that, but why force people who prefer the mailing-list to comment on GitHub? We don't force anything. We create PR's to keep it consistent. >> >We create them because the changes are then easily put into our review system and we can actually keep track of them. With the ML's the patches can get lost in the signal/noise ratio. > I don't see how patches can get lost on erlang-patches, it's not like bugs, questions and patches end up in the same place. Forgotten, unhandled or in a big bag of mail-threads, i.e. lost. >> >We at OTP don't use GitHub for bug-tracking, we merely use GH as a conduit to you, the community, and it seemed like the most effective tool for us to do this. We can also automate certain things for it, like doc and build testing. Saves time. > Couldn't you improve your internal bug-tracking to expose some parts of it to the public? That would certainly make things more future proof. We could in an ideal world. Actually that's what I want and with a sync to github. We don't have the time to do that now though. >> >I don't share your concern that the history of a pull requsts can change or gets lost (deleted). I mean, I do belive this might happen but the information in a PR should translate to an OTP-ticket and all the relevant information should be either in the commit message or the ticket (or both). I view PR and ML information as transient data to forward the work of the patch. The relevant information should be in the commit message when final. > I can download the whole erlang-patches archives, I have already found interesting stuff in it. When we switch off GitHub in a few years, this won't be doable for everything that will have happened meanwhile. Yes, i've heard this before. "Le'ts reduce it to the crudest form so we can rebuild it later." >> >But I've certianly been the there. Pondering "what were they thinking" when reviewing legacy code. In Git, this information should be in the commit message .. not in a mail discussion (or in a PR). So if anything, we should be even harder on clear and informative commit messages. > That's an ideal, but reality says otherwise. Especially so for rejected patches where there is no commit, by definition (e.g. the previous attempts to fix the =<< situation). I do not think Mailing Lists is the solution though. It is not structured enough. >> >I think we should give GitHub a little more time. I think pull requests is a nice addition as it saves time for us. ML's are just awful in this regard. I don't think we have found the optimal ways of working with GitHub, ML's and patches yet. We are still learning. > The initial point of supporting GitHub's PRs was to make the work easier for the community, not the OTP team. Nice one. Seriously Anthony, that is low. The community expresses a whish, go github. We follow and add github pr's and it actually turns out it makes things easier for us. You then say it is a mute point? That is low. I agree with you that archiving can be a problem. I actually get all PR's as mails. I think others can to by watching the PR's. That might solve your problem. I like others to weigh in too. Are PR's as bad as Anthony points out? Should we kill it and use mails only? // Bj?rn-Egil From vinoski@REDACTED Tue Oct 22 14:09:27 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 22 Oct 2013 08:09:27 -0400 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <52666774.4030203@erlang.org> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> Message-ID: On Tue, Oct 22, 2013 at 7:54 AM, Bj?rn-Egil Dahlberg wrote: > Are PR's as bad as Anthony points out? Should we kill it and use mails > only? > No, please please don't do that. I'm a big +1 for PRs -- IMO they work much better than previous approaches, and I've heard similar positive opinions from a number of coworkers and from folks at recent Erlang meetups in the US and Europe. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Oct 22 14:20:54 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 22 Oct 2013 14:20:54 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> Message-ID: Pull requests are working well for me too but I have only done minor contributions via PRs so far. I particularly enjoyed that I got feedback from "OTP Maintainer" early on. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Tue, Oct 22, 2013 at 2:09 PM, Steve Vinoski wrote: > > > > On Tue, Oct 22, 2013 at 7:54 AM, Bj?rn-Egil Dahlberg wrote: > >> Are PR's as bad as Anthony points out? Should we kill it and use mails >> only? >> > > No, please please don't do that. I'm a big +1 for PRs -- IMO they work > much better than previous approaches, and I've heard similar positive > opinions from a number of coworkers and from folks at recent Erlang meetups > in the US and Europe. > > --steve > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh@REDACTED Tue Oct 22 14:25:32 2013 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Tue, 22 Oct 2013 08:25:32 -0400 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> Message-ID: <7E7F6BBE-E163-464E-9E4A-34CA47C184D6@dieswaytoofast.com> "What Steve Said" Seriously, I too am a big +1 for the PRs. Most of the (minor) complaining that I've heard tends to stem around "make it even better", which really isn't a reason to eliminate this... Cheers Mahesh Paolini-Subramanya That Tall Bald Indian Guy... Google+ | Blog | Twitter | LinkedIn On Oct 22, 2013, at 8:09 AM, Steve Vinoski wrote: > > > > On Tue, Oct 22, 2013 at 7:54 AM, Bj?rn-Egil Dahlberg wrote: > Are PR's as bad as Anthony points out? Should we kill it and use mails only? > > No, please please don't do that. I'm a big +1 for PRs -- IMO they work much better than previous approaches, and I've heard similar positive opinions from a number of coworkers and from folks at recent Erlang meetups in the US and Europe. > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 22 14:44:58 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 22 Oct 2013 14:44:58 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <52666774.4030203@erlang.org> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> Message-ID: I didn't say it is a mute point, I just stated that it was not the intended move. If the community as a whole should just use pull requests then I will reluctantly use pull requests. I have never argued for not using them, just that I don't really enjoy being forced to use them when I prefer the previous work flow. Yes, GitHub can mail notifications. Yes, they can be archived. Do we have a bot that archives the various comments? No, we don't. Will people who start to contribute in a few years be able to look back at all the discussions that occurred before without such a bot? Maybe, maybe not, depends on whether GitHub is still alive or hasn't been bought by a less scrupulous entity (who knows). Make a tool that does the same thing as the erlang-patches archive page from the PR comments and I will happily wave the white flag. I am not arguing just for the sake of keeping my own work flow the same (nobody likes changing his habits, right?), but because it is arguably better in the long-term, with regard to archiving and not losing knowledge. -- Anthony Ramine Le 22 oct. 2013 ? 13:54, Bj?rn-Egil Dahlberg a ?crit : > Seriously Anthony, that is low. The community expresses a whish, go github. We follow and add github pr's and it actually turns out it makes things easier for us. You then say it is a mute point? That is low. From n.oxyde@REDACTED Tue Oct 22 14:49:36 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 22 Oct 2013 14:49:36 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <7E7F6BBE-E163-464E-9E4A-34CA47C184D6@dieswaytoofast.com> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> <7E7F6BBE-E163-464E-9E4A-34CA47C184D6@dieswaytoofast.com> Message-ID: The problem is that the "make it even better" is mostly out of our control. Immutable comments? GitHub's work. Search in past pull requests and comments? GitHub's work (yes it has a search engine already, but sometimes it can't even find what Google did). -- Anthony Ramine Le 22 oct. 2013 ? 14:25, Mahesh Paolini-Subramanya a ?crit : > Seriously, I too am a big +1 for the PRs. > Most of the (minor) complaining that I've heard tends to stem around "make it even better", which really isn't a reason to eliminate this... From n.oxyde@REDACTED Tue Oct 22 15:05:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 22 Oct 2013 15:05:16 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> Message-ID: I know, that's why I suggested that as a compromise. Or are you implying that I should do such a thing myself? -- Anthony Ramine Le 22 oct. 2013 ? 15:03, Mikhail Gusarov a ?crit : > On Tue, Oct 22, 2013 at 2:44 PM, Anthony Ramine wrote: > >> Make a tool that does the same thing as the erlang-patches archive page from the PR comments and I will happily wave the white flag. > > Creating GitHub account for some Mailman list instance and subscribing > this account to needed repositories is a 5-minute work. > > Best regards, > Mikhail Gusarov. From dch@REDACTED Tue Oct 22 15:18:27 2013 From: dch@REDACTED (Dave Cottlehuber) Date: Tue, 22 Oct 2013 15:18:27 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: <52666774.4030203@erlang.org> References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> Message-ID: >>> >I think we should give GitHub a little more time >> ?I think pull requests is a nice addition as it saves time for us. ML's are just awful in this regard. I don't think we have found the optimal ways of working with GitHub, ML's and patches yet. We are still learning. >> The initial point of supporting GitHub's PRs was to make the work easier for the community, not the OTP team. >I agree with you that archiving can be a problem. I actually get all >PR's as mails. I think others can to by watching the PR's. That might >solve your problem. > >I like others to weigh in too. > >Are PR's as bad as Anthony points out? Should we kill it and use mails only? > >// Bj?rn-Egil Hi Bj?rn-Egil, Anthony & all, Let's not paint this as an either-or choice. I think we can use both.?The Apache Software Foundation has already been down this path, for projects like Cordova and CouchDB, successfully. TL;DR keep the PRs and forward all commentary to erlang-bugs/patches/something-new and everybody should be happy. Here's my personal view; - It's great that Ericsson's OTP team are continually improving their engagement with the community. You are doing fantastic work and it's winning all the way down. \o/ more please! - submitting changes via PR instead of directly on the mailing list is clean and tidy, with better visibility when viewed in context like a diff or changed files view. - However, the comments & discussions within the github thread are easily lost. For those who are not interested in subscribing to a full erlang-questions/patches/bugs list, it's ideal for keeping up to date on a fix that individual submitted. - Subscribing (watching) the whole repo could be a lot of unwanted noise. A+ @dch From egil@REDACTED Tue Oct 22 16:59:14 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 22 Oct 2013 16:59:14 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> Message-ID: <526692C2.6000704@erlang.org> On 2013-10-21 20:04, Tuncer Ayaz wrote: > On Mon, Oct 21, 2013 at 6:28 PM, Bjorn-Egil Dahlberg wrote: >> Just to say why we create pull requests for most (all?) patches >> nowadays. > Should we skip sending mails to erlang-patches@ from now on? No, we'll keep it as is for now. We at OTP would prefer Pull Requsts though, it's less of a hassle but erlang-patches is ok as well. Some people even insist on writing mail diff patches and we include them as well if they are totally hassle free and/or really significant. >> We at OTP don't use GitHub for bug-tracking, we merely use GH as a >> conduit to you, the community, and it seemed like the most effective >> tool for us to do this. We can also automate certain things for it, >> like doc and build testing. Saves time. > Given the use of pull requests for otp.git, what about automatically > syncing bugs to/from https://github.com/erlang/otp/issues? No, I don't think we should use GH Issues at all. It seems lacking in usability, at least when I've tried them for other projects. > >>> I don't care about pull requests for typos, but that's all they >>> should be used for. >> My thoughts on this. >> >> I will certianly agree with you that GH has shortcomings. Especially >> with issue tracking but also with pull requests (to a lesser >> degree). I don't think we will ever use the issue tracking on GH as >> it is just plain awful for larger projects but it might be suitable >> for other things, like community driven tasks. >> >> I don't share your concern that the history of a pull requsts can >> change or gets lost (deleted). I mean, I do belive this might happen > I think Anthony is right, and using the patch-queue approach of a > cleanly rebased branch, code comments can also disappear. I haven't > figured out the pattern yet, but sometimes after a rebase old comments > are still linked but collapsed, and sometimes they're gone. I prefer > Gerrit's code review functionality for this particularly feature. > Also, the way github inserts new commits into the discussion is > debatable. I belive GH PRs are good enough. Transient data to forward the work of the patch. Code comments are also transient and should be treated as such. We won't add Gerrit or any other tools atm. // Bj?rn-Egil From eriksoe@REDACTED Tue Oct 22 17:45:32 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 22 Oct 2013 17:45:32 +0200 Subject: [erlang-questions] Synchronous way to handle timeout between gen_server(s) In-Reply-To: References: Message-ID: Arun: It's not that kind of timeout. - Returning {reply, Reply, State, Timeout} is what triggers handle_info(timeout, ...) in case the process doesn't *get a message while idle* within the timeout period; - Performing a gen_server:call(...) is what triggers a *timeout exception* in case the process doesn't *get a reply while calling* within the timeout period. Just to clear things up :-) 2013/10/22 Arun Muralidharan > Not 100% sure, but you can catch the timeout with handle_info. > Somethig like > handle_info(timeout, State)-> > # do something . > > -Arun > > > On Tue, Oct 22, 2013 at 4:16 PM, Attila Rajmund Nohl < > attila.r.nohl@REDACTED> wrote: > >> Hello! >> >> Exactly what would you like to achieve? If you don't expect serv2 to >> freeze, you can set the timeouts in the gen_server:calls to infinity. >> >> 2013/10/22 Tien Le : >> > Hi, >> > >> > Please look at my sample code below. I have 2 gen_servers (serv1 and >> serv2). >> > serv1 start_link serv2, and traps exit. >> > >> > %%% serv1:do/0 implementation: %%% >> > do() -> >> > gen_server:call(serv1, do). >> > >> > handle_call(do, _From, State) -> >> > Result = serv2:do(), >> > {reply, Result, State}. >> > >> > >> > %%% serv2:do/0 implementation: %%% >> > do() -> >> > gen_server:call(serv2, do). >> > >> > handle_call(do, _From, State) -> >> > %% Something that takes time like timer:sleep/1 >> > Result = timer:sleep(5000), >> > {reply, Result, State}. >> > >> > >> > As you can see that serv1's gen_server:call and serv2's gen_server:call >> have >> > the same timeout value (5000ms by default). >> > >> > When I call serv1:do(). >> > serv1 always terminates first due to timed out: >> > >> > =CRASH REPORT==== 22-Oct-2013::10:26:38 === >> > crasher: >> > initial call: serv1:init/1 >> > pid: <0.43.0> >> > registered_name: serv1 >> > exception exit: {timeout,{gen_server,call,[serv2,do]}} >> > in function gen_server:terminate/6 (gen_server.erl, line 747) >> > ... >> > >> > One workaround is to increase the timeout of serv1 and serv2 >> > gen_server:call/3, like this: >> > gen_server:call(serv1, do, 5020) => gen_server:call(serv2, do, 5010) => >> > timer:sleep(5000) >> > >> > I would like to ask you if there's any nicer and synchronous way to >> handle >> > the timeout in this case? >> > >> > >> > >> > _______________________________________________ >> > 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 dottedmag@REDACTED Tue Oct 22 15:03:21 2013 From: dottedmag@REDACTED (Mikhail Gusarov) Date: Tue, 22 Oct 2013 15:03:21 +0200 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> Message-ID: On Tue, Oct 22, 2013 at 2:44 PM, Anthony Ramine wrote: > Make a tool that does the same thing as the erlang-patches archive page from the PR comments and I will happily wave the white flag. Creating GitHub account for some Mailman list instance and subscribing this account to needed repositories is a 5-minute work. Best regards, Mikhail Gusarov. From ferenc.holzhauser@REDACTED Tue Oct 22 18:20:54 2013 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Tue, 22 Oct 2013 18:20:54 +0200 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: References: Message-ID: Thanks for the suggestions and hints. I think I accidentally found a strange workaround. Spawned a simple recursive function doing this inside: receive after 500 -> io:format("~p", [calendar:local_time()]) end so I can see when exactly it stops working and perhaps find something around that time in the logs. Since doing this, I can't reproduce the issue. Now I spawn the function without the io:format bit (returning ok) and the VM is stable (so far). It doesn't make a lot of sense to me and I'm really curious to find out what is happening. Perhaps someone with better understanding than mine of the internals of "receive after" has some ideas what situation can deadlock it this way. Probably there are not many ways to "achieve" that. Could it be possibly related to SCTP socket handling? Namely that's the only thing (remote disconnect/reconnect) I could see my application was doing around when the problem might have happened. Regards, Ferenc On 19 October 2013 21:51, Anthony Molinaro wrote: > I don't know if a work around probably make sure you are running the most > recent version of virtual box? And make make sure to give it multiple > cores. You could also convert the vm to a different format (like VMware), > and see if it works better. > > -Anthony > > On Oct 18, 2013, at 1:29 PM, Ferenc Holzhauser < > ferenc.holzhauser@REDACTED> wrote: > > Hi Anthony, > > That must be it: it is running in virtualbox indeed. Are you aware of any > workaround/fix to try? I'm quite attached to this VM setup. Would be great > if I could make it work reliably. > > Ferenc > On Oct 18, 2013 9:35 PM, "Anthony Molinaro" > wrote: > >> Are you running in some sort of virtualized environment. I seem to >> recall noticing some oddness with timer:send_interval/2 under VMware at one >> point, but it's a total guess so may not be your issue at all. >> >> -Anthony >> >> On Oct 18, 2013, at 11:50 AM, Ferenc Holzhauser < >> ferenc.holzhauser@REDACTED> wrote: >> >> > Hi, >> > >> > On my development system sometimes "receive after..." starts hanging >> after a while. >> > I know "sometimes" is not very helpful but I couldn't find any >> obviously related event yet that might trigger it. >> > >> > From that point it stops working in the whole VM e.g. I can type >> "receive after 10 -> ok end." in the shell and watch it never returning. Of >> course it also breaks most of the things that need timer. >> > Normal receive keeps working fine, the issue is related to timeout only. >> > >> > It is R16B01 and I'm not using any self made NIFs, drivers or other >> funny things that could break the VM. >> > >> > Thank you for any hints or suggestions about the possible reason/fix in >> advance. >> > >> > Regards, >> > Ferenc >> > >> > >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Tue Oct 22 18:50:03 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 22 Oct 2013 18:50:03 +0200 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: References: Message-ID: Two ideas: - The shell's receive-after implementation was flawed until recently (I *think* it was fixed...): The timeout was reset upon the receipt of *any* new message. - On some virtualized environments, the high-resolution timer is flawed: once every perhaps 100 milion reads, it jumps by a very large amount, then jumps back. This can be deadly to the Erlang VM. (And also the JVM, by the way). Wheter the platform has this problem can be checked by writing and running a small C program which reads the timer ("gethrtimer"?) as often as it can, checking for time jumps each time. Good luck hunting... 2013/10/22 Ferenc Holzhauser > Thanks for the suggestions and hints. > > I think I accidentally found a strange workaround. > Spawned a simple recursive function doing this inside: > > receive after 500 -> io:format("~p", [calendar:local_time()]) end > > so I can see when exactly it stops working and perhaps find something > around that time in the logs. > > > Since doing this, I can't reproduce the issue. Now I spawn the function > without the io:format bit (returning ok) and the VM is stable (so far). > > It doesn't make a lot of sense to me and I'm really curious to find out > what is happening. > Perhaps someone with better understanding than mine of the internals of > "receive after" has some ideas what situation can deadlock it this way. > Probably there are not many ways to "achieve" that. > > Could it be possibly related to SCTP socket handling? Namely that's the > only thing (remote disconnect/reconnect) I could see my application was > doing around when the problem might have happened. > > Regards, > Ferenc > > > > > On 19 October 2013 21:51, Anthony Molinaro wrote: > >> I don't know if a work around probably make sure you are running the most >> recent version of virtual box? And make make sure to give it multiple >> cores. You could also convert the vm to a different format (like VMware), >> and see if it works better. >> >> -Anthony >> >> On Oct 18, 2013, at 1:29 PM, Ferenc Holzhauser < >> ferenc.holzhauser@REDACTED> wrote: >> >> Hi Anthony, >> >> That must be it: it is running in virtualbox indeed. Are you aware of any >> workaround/fix to try? I'm quite attached to this VM setup. Would be great >> if I could make it work reliably. >> >> Ferenc >> On Oct 18, 2013 9:35 PM, "Anthony Molinaro" >> wrote: >> >>> Are you running in some sort of virtualized environment. I seem to >>> recall noticing some oddness with timer:send_interval/2 under VMware at one >>> point, but it's a total guess so may not be your issue at all. >>> >>> -Anthony >>> >>> On Oct 18, 2013, at 11:50 AM, Ferenc Holzhauser < >>> ferenc.holzhauser@REDACTED> wrote: >>> >>> > Hi, >>> > >>> > On my development system sometimes "receive after..." starts hanging >>> after a while. >>> > I know "sometimes" is not very helpful but I couldn't find any >>> obviously related event yet that might trigger it. >>> > >>> > From that point it stops working in the whole VM e.g. I can type >>> "receive after 10 -> ok end." in the shell and watch it never returning. Of >>> course it also breaks most of the things that need timer. >>> > Normal receive keeps working fine, the issue is related to timeout >>> only. >>> > >>> > It is R16B01 and I'm not using any self made NIFs, drivers or other >>> funny things that could break the VM. >>> > >>> > Thank you for any hints or suggestions about the possible reason/fix >>> in advance. >>> > >>> > Regards, >>> > Ferenc >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 anthonym@REDACTED Tue Oct 22 18:54:10 2013 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Tue, 22 Oct 2013 09:54:10 -0700 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: References: Message-ID: This make's it sound more and more like a VM issue. You essentially have a busy loop there which keeps your host from noticing the container is idle, and putting it to sleep. You could probably achieve the same thing by having a second shell and doing something like #> while true ; do date ; sleep 1 ; done which should prevent the host from think the container is idle. Although since it's a sleep 1, that might be enough time to see the pauses happening. You could also try your busy loop with a larger number like 1000, or 5000 and see if the pauses come back. -Anthony On Oct 22, 2013, at 9:20 AM, Ferenc Holzhauser wrote: > Thanks for the suggestions and hints. > > I think I accidentally found a strange workaround. > Spawned a simple recursive function doing this inside: > > receive after 500 -> io:format("~p", [calendar:local_time()]) end > > so I can see when exactly it stops working and perhaps find something around that time in the logs. > > > Since doing this, I can't reproduce the issue. Now I spawn the function without the io:format bit (returning ok) and the VM is stable (so far). > > It doesn't make a lot of sense to me and I'm really curious to find out what is happening. > Perhaps someone with better understanding than mine of the internals of "receive after" has some ideas what situation can deadlock it this way. Probably there are not many ways to "achieve" that. > > Could it be possibly related to SCTP socket handling? Namely that's the only thing (remote disconnect/reconnect) I could see my application was doing around when the problem might have happened. > > Regards, > Ferenc > > > > > On 19 October 2013 21:51, Anthony Molinaro wrote: > I don't know if a work around probably make sure you are running the most recent version of virtual box? And make make sure to give it multiple cores. You could also convert the vm to a different format (like VMware), and see if it works better. > > -Anthony > > On Oct 18, 2013, at 1:29 PM, Ferenc Holzhauser wrote: > >> Hi Anthony, >> >> That must be it: it is running in virtualbox indeed. Are you aware of any workaround/fix to try? I'm quite attached to this VM setup. Would be great if I could make it work reliably. >> >> Ferenc >> >> On Oct 18, 2013 9:35 PM, "Anthony Molinaro" wrote: >> Are you running in some sort of virtualized environment. I seem to recall noticing some oddness with timer:send_interval/2 under VMware at one point, but it's a total guess so may not be your issue at all. >> >> -Anthony >> >> On Oct 18, 2013, at 11:50 AM, Ferenc Holzhauser wrote: >> >> > Hi, >> > >> > On my development system sometimes "receive after..." starts hanging after a while. >> > I know "sometimes" is not very helpful but I couldn't find any obviously related event yet that might trigger it. >> > >> > From that point it stops working in the whole VM e.g. I can type "receive after 10 -> ok end." in the shell and watch it never returning. Of course it also breaks most of the things that need timer. >> > Normal receive keeps working fine, the issue is related to timeout only. >> > >> > It is R16B01 and I'm not using any self made NIFs, drivers or other funny things that could break the VM. >> > >> > Thank you for any hints or suggestions about the possible reason/fix in advance. >> > >> > Regards, >> > Ferenc >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 Tue Oct 22 20:15:31 2013 From: gumm@REDACTED (Jesse Gumm) Date: Tue, 22 Oct 2013 13:15:31 -0500 Subject: [erlang-questions] On Pull Requests Comments In-Reply-To: References: <6460E241-AFB2-448C-A12E-789B94181EEC@gmail.com> <52650C85.50207@ninenines.eu> <52655631.3060909@erlang.org> <02716CCD-15FF-4936-80A3-DE2FB1A19C0A@gmail.com> <52666774.4030203@erlang.org> <7E7F6BBE-E163-464E-9E4A-34CA47C184D6@dieswaytoofast.com> Message-ID: One option could be using gitlab.org, which is an open source clone of github (I believe also in Rails). There's another out there as well which I think is in Java (I forget the name, it was on HN a few weeks ago), but the point being that you could get the familiar interface of github while also having full control over the data and then it might be easier to integrate that open source system with your internal systems. You do sacrifice the user-base of Github, though. But if there's enough backlash against github, maybe worth a look. But I'm also in the "Yay Github +1" crowd. -Jesse On Tue, Oct 22, 2013 at 7:49 AM, Anthony Ramine wrote: > The problem is that the "make it even better" is mostly out of our control. > > Immutable comments? GitHub's work. > Search in past pull requests and comments? GitHub's work (yes it has a search engine already, but sometimes it can't even find what Google did). > > -- > Anthony Ramine > > Le 22 oct. 2013 ? 14:25, Mahesh Paolini-Subramanya a ?crit : > >> Seriously, I too am a big +1 for the PRs. >> Most of the (minor) complaining that I've heard tends to stem around "make it even better", which really isn't a reason to eliminate this... > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm From tom@REDACTED Wed Oct 23 03:56:39 2013 From: tom@REDACTED (Tom Samplonius) Date: Tue, 22 Oct 2013 18:56:39 -0700 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: References: Message-ID: <9CFC8C5C-6C15-40C4-8940-34284E58BE0E@samplonius.org> On 2013-10-18, at 1:29 PM, Ferenc Holzhauser wrote: > Hi Anthony, > > That must be it: it is running in virtualbox indeed. Are you aware of any workaround/fix to try? I'm quite attached to this VM setup. Would be great if I could make it work reliably. > > Ferenc > You may want to try Virtualbox 4.3.0, released a few days. This is listed in the release notes for 4.30: * VMM: major rewrite of the VT-x code and the AMD-V code including many bug fixes and performance improvements (for example https://www.virtualbox.org/ticket/9659) Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Wed Oct 23 13:06:30 2013 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Wed, 23 Oct 2013 14:06:30 +0300 Subject: [erlang-questions] Atomically updating a record in ETS table Message-ID: <5267ADB6.8030002@gmail.com> Hello everyone, I have an ETS table that contains records of the following format: {Key, List} For example, {key123, [a,b,c]}. Now I have to add to the list a new item, say 'd'. I have to select the record, add the new value to the list and replace the record with the new list. But how to do this atomically? Many processes might try to add an item to a record. Some sort of "critical section"? Thanks in advance, Martin From dmkolesnikov@REDACTED Wed Oct 23 13:12:48 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 23 Oct 2013 14:12:48 +0300 Subject: [erlang-questions] Atomically updating a record in ETS table In-Reply-To: <5267ADB6.8030002@gmail.com> References: <5267ADB6.8030002@gmail.com> Message-ID: <3D7D6E95-A8EE-430A-993F-36DEB1FCA19F@gmail.com> Hello, There is ets:update_element but it works with tuples only. I am afraid that you need to handle write/update operation through server (gen_server). For high-throughput, you might need to implement multiple servers with consistent hash schema. Best Regards, Dmitry On Oct 23, 2013, at 2:06 PM, Martin Dimitrov wrote: > Hello everyone, > > I have an ETS table that contains records of the following format: > > {Key, List} > > For example, {key123, [a,b,c]}. Now I have to add to the list a new > item, say 'd'. I have to select the record, add the new value to the > list and replace the record with the new list. But how to do this > atomically? Many processes might try to add an item to a record. Some > sort of "critical section"? > > Thanks in advance, > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Wed Oct 23 13:18:24 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 23 Oct 2013 13:18:24 +0200 Subject: [erlang-questions] Atomically updating a record in ETS table In-Reply-To: <5267ADB6.8030002@gmail.com> References: <5267ADB6.8030002@gmail.com> Message-ID: On Wed, Oct 23, 2013 at 1:06 PM, Martin Dimitrov wrote: > For example, {key123, [a,b,c]}. Now I have to add to the list a new > item, say 'd'. I have to select the record, add the new value to the > list and replace the record with the new list. But how to do this > atomically? > In this case, you may want to look at the "bag" table type, or perhaps "duplicate bag". It will almost always be a better representation than having to run the overhead of copying your list back and forth between a process and ETS. Dmitry's suggestion is good as well. Serialize writes to the table through a single process. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Oct 23 13:21:28 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 23 Oct 2013 14:21:28 +0300 Subject: [erlang-questions] how to unsubscribe inactive user? References: <20131023112022.7AD9C246885B@lgq.gov.cn> Message-ID: Hello, Is it possible to exclude user ygzjcc@REDACTED from mailing list? This is really annoying to receive spam from him. I think this user is not active anymore, here is english translation of his auto-respond message? You sent (ygzjcc@REDACTED) messages are not delivered successfully, because the other mailbox is full. Original letter in the Annex. Best Regards, Dmitry Begin forwarded message: > From: MAILER-DAEMON@REDACTED > Subject: ??????????? > Date: October 23, 2013 2:20:22 PM GMT+03:00 > To: Dmitry Kolesnikov > > ???(ygzjcc@REDACTED)??????????????????????????? > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 5477 URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Wed Oct 23 14:06:32 2013 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Wed, 23 Oct 2013 15:06:32 +0300 Subject: [erlang-questions] Atomically updating a record in ETS table In-Reply-To: References: <5267ADB6.8030002@gmail.com> Message-ID: <5267BBC8.2000300@gmail.com> Thanks for the replies. I will pass the update procedure thru a gen_server. Regards, Martin On 10/23/2013 2:18 PM, Jesper Louis Andersen wrote: > On Wed, Oct 23, 2013 at 1:06 PM, Martin Dimitrov wrote: > >> For example, {key123, [a,b,c]}. Now I have to add to the list a new >> item, say 'd'. I have to select the record, add the new value to the >> list and replace the record with the new list. But how to do this >> atomically? >> > > In this case, you may want to look at the "bag" table type, or perhaps > "duplicate bag". It will almost always be a better representation than > having to run the overhead of copying your list back and forth between a > process and ETS. Dmitry's suggestion is good as well. Serialize writes to > the table through a single process. > > From raimo+erlang-questions@REDACTED Wed Oct 23 14:50:11 2013 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 23 Oct 2013 14:50:11 +0200 Subject: [erlang-questions] how to unsubscribe inactive user? In-Reply-To: References: <20131023112022.7AD9C246885B@lgq.gov.cn> Message-ID: <20131023125009.GD25927@erix.ericsson.se> On Wed, Oct 23, 2013 at 02:21:28PM +0300, Dmitry Kolesnikov wrote: > Hello, > > Is it possible to exclude user ygzjcc@REDACTED from mailing list? > This is really annoying to receive spam from him. Done. Mailman detects and tries to recognize bounces, but it seems has not managed to parse those. Thank you for reporting this. > > I think this user is not active anymore, here is english translation of his auto-respond message? > > You sent (ygzjcc@REDACTED) messages are not delivered successfully, because the other mailbox is full. Original letter in the Annex. > > Best Regards, > Dmitry > > Begin forwarded message: > > > From: MAILER-DAEMON@REDACTED > > Subject: ??????????? > > Date: October 23, 2013 2:20:22 PM GMT+03:00 > > To: Dmitry Kolesnikov > > > > ???(ygzjcc@REDACTED)??????????????????????????? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From francis.joanis@REDACTED Wed Oct 23 19:07:26 2013 From: francis.joanis@REDACTED (Francis Joanis) Date: Wed, 23 Oct 2013 13:07:26 -0400 Subject: [erlang-questions] Erlang cluster over a WAN link? In-Reply-To: References: Message-ID: Hi, I haven't had a lot of experience with actual Erlang clusters separated between a WAN, but if you are only talking about 2 nodes then I suspect the actual cluster connection will be almost identical to using vanilla TCP connection. Once connected, the distributed nodes will use the Erlang Distribution Protocol which is built on top of TCP. If you were to use a plain TCP socket you would still need to come up with some kind of protocol to stream data over the connection. Chances are that this protocol will look a lot like the built-in Erlang Distribution Protocol (especially if you use term_to_binary/binary_to_term). One difference that the EDP will have is a requirement to work with epmd and this might cause you some more headaches in terms of firewall configuration (to make the epmd port + the dynamically allocated EDP port available). It depends on the type of application you are dealing with. If you need deterministic/real time behavior then maybe TCP and/or WAN isn't a good choice to start with (TCP will try to throttle connections to avoid congestion, etc., so you might end up with delays being added at the TCP level). UDP could have a more real time behavior but you would need to implement your own reliability/congestion management layer on top of it (or use an alternative transport). If you can tolerate these delays, I'd say try it and see how it flies. There are tools available that can let you simulate delays/bandwidth/packet loss so that you can try it using a few VMs without an actual WAN connection. One of those is dummynet (available on FreeBSD and others). With the EDP, if you need more than two nodes, you could control how the "meshing" of the nodes is done using the VM "-connect_all false" flag (otherwise it would try to create a lot of TCP connections to form a mesh). There is also this flag that would apply to control the "heartbeating" of the nodes: net_ticktime (http://erlang.org/doc/man/kernel_app.html). You might also find these useful: https://erlangcentral.org/wiki/index.php?title=Distributed_erlang_using_ssl_through_firewalls http://fjoanis.github.io/2013/08/31/Network_Simulation_FreeBSD_DummyNet/ Salut, Francis On Mon, Oct 7, 2013 at 4:13 AM, Alexandre Beaulne wrote: > Hello everyone, > > I am working on two tightly coupled (but physically separated) Erlang apps > communicating between each other by TCP over a WAN link. I was curious why > an Erlang cluster wasn't used in this case and searched around a bit with no > clear cut answer. I read that it's generally a bad idea to set up a RabbitMQ > cluster using WAN instead of LAN, but if I understand well it has to do with > the fact that RabbitMQ lies on the Availability/Partition-tolerance axis of > the CAP theorem while in our case we'd be more on the > Consistency/Partition-tolerance axis so it might make it more suitable for a > cluster? The WAN in question is a leased line that has been solid > historically and the number of nodes will probably stay at 2 in the > foreseeable future. > > Anyone here has successfully run an Erlang cluster over a WAN link? > > Is there good reasons to use a plain vanilla TCP connection rather than an > Erlang cluster in this use case? > > It is sad to have a nice, concurrent Erlang application having to funnel > into a single, sequential "TCP" process only to re-branch on the other side > of the connection... > > Thank you very much for you time, > > Alexandre Beaulne > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From askjuise@REDACTED Wed Oct 23 21:26:52 2013 From: askjuise@REDACTED (Alexander Petrovsky) Date: Wed, 23 Oct 2013 23:26:52 +0400 Subject: [erlang-questions] run strange behaviour Message-ID: Hi! I have the regex "^foo (\\w+(\\w* *)*) is an (\\w+(\\w* *)*)", and I get strange behaviour when I do: 1> re:run(<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], binary}]). {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]} 2> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], binary}]). nomatch I tested this regexp in clojure and python: => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a foo bar is a big yellow boat or") ["foo bar is a foo bar is a big yellow boat or" "bar is a foo bar" "" "big yellow boat or" ""] => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a foo bar is a big yellow boat or sub") ["foo bar is a foo bar is a big yellow boat or sub" "bar is a foo bar" "" "big yellow boat or sub" ""] >>> import re >>> p = re.compile('foo (\w+(\w* *)*) is a (\w+(\w* *)*)') >>> p.match("foo bar is a foo bar is a big yellow boat or") <_sre.SRE_Match object at 0x100293c00> >>> p.match("foo bar is a foo bar is a big yellow boat or sub") <_sre.SRE_Match object at 0x100293ab0> Can someone explain me, why I get on second string "foo bar is a foo bar is a big yellow boat or sub" nomatch? This is a bug? -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Jabber: juise@REDACTED Phone: +7 914 8 820 815 (irkutsk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Thu Oct 24 00:35:58 2013 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Wed, 23 Oct 2013 15:35:58 -0700 Subject: [erlang-questions] DocBuilder Removed in R16 Message-ID: <1382567758.24067.37745693.61B2535D@webmail.messagingengine.com> Hopefully this hasn't already been dealt with on here. I was wondering if anyone knew why DocBuilder app was removed and what to use in its place: https://github.com/fenollp/erldocs/issues/2 -- Tristan Sloughter tristan.sloughter@REDACTED From donpedrothird@REDACTED Thu Oct 24 01:07:51 2013 From: donpedrothird@REDACTED (John Doe) Date: Thu, 24 Oct 2013 03:07:51 +0400 Subject: [erlang-questions] Old and new crypto: sign, rsa_sign, verify, rsa_verify compatibility Message-ID: Hi, Is it possible to make RSA signatures compatible between old and new crypto methods? I can't find a way how to do this. Here's an example, run in R16B02: crypto:start(). %% these two keys are valid RSA keypair PrivateKey = [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>,<<0,0,0,64,104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57,194,30,29,119,116,166,32,71,194,252,162,197,193,144,84,98,223,170,137,84,25,86,2,237,128,201,216,139,98,173,122,229,3,62,100,69,241,18,186,249,170,25,156,172,32,228,180,129>>]. PublicKey = [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>]. SizedBinary = fun(Binary) -> <<(size(Binary)):32/integer, Binary/binary>> end. Payload = <<"Launch the nukes.">>. Hash = crypto:sha(Payload). %%signed with old method Signature = crypto:rsa_sign(SizedBinary(Hash), PrivateKey). %%verify with old method - returns true crypto:rsa_verify(SizedBinary(Hash), SizedBinary(Signature), PublicKey). %%new method - returns false crypto:verify(rsa, sha, {digest, Hash}, Signature, PublicKey). %%another try of new method - throws an 'bad argument' exception crypto:verify(rsa, sha, {digest, SizedBinary(Hash)}, SizedBinary(Signature), PublicKey). %%new method yet again - returns false crypto:verify(rsa, sha, {digest, Hash}, SizedBinary(Signature), PublicKey). -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.levytskyy@REDACTED Thu Oct 24 02:55:12 2013 From: v.levytskyy@REDACTED (Vyacheslav Levytskyy) Date: Thu, 24 Oct 2013 03:55:12 +0300 Subject: [erlang-questions] run strange behaviour In-Reply-To: References: Message-ID: <52686FF0.6080407@yahoo.com> Hello, According to 're' module documentation, "the quantifiers are "greedy", that is, they match as much as possible (up to the maximum number of permitted times)". This seems to be a problem with your case. The regex you are using seems a bit problematic, forcing 're' to exhausting repetitions. As an option, you can use 'ungreedy' option, making only some of quantifiers greedy via following them by "?". See for example: re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo (\\w(\\w+| )*) is a (\\w(\\w+?| )*?)">>, [ungreedy, global, {capture, [1,3], binary}]). {match,[[<<"bar">>, <<"foo bar is a big yellow boat or sub">>]]} Best regards, Vyacheslav Levytskyy On 23.10.2013 22:26, Alexander Petrovsky wrote: > Hi! > > I have the regex "^foo (\\w+(\\w* *)*) is an (\\w+(\\w* *)*)", and I > get strange behaviour when I do: > > 1> re:run(<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo > (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], > binary}]). > {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]} > > 2> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, > <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, > [1,3], binary}]). > nomatch > > I tested this regexp in clojure and python: > > => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a > foo bar is a big yellow boat or") > ["foo bar is a foo bar is a big yellow boat or" "bar is a foo bar" "" > "big yellow boat or" ""] > > => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a > foo bar is a big yellow boat or sub") > ["foo bar is a foo bar is a big yellow boat or sub" "bar is a foo bar" > "" "big yellow boat or sub" ""] > > >>> import re > >>> p = re.compile('foo (\w+(\w* *)*) is a (\w+(\w* *)*)') > >>> p.match("foo bar is a foo bar is a big yellow boat or") > <_sre.SRE_Match object at 0x100293c00> > >>> p.match("foo bar is a foo bar is a big yellow boat or sub") > <_sre.SRE_Match object at 0x100293ab0> > > Can someone explain me, why I get on second string "foo bar is a foo > bar is a big yellow boat or sub" nomatch? This is a bug? > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Jabber: juise@REDACTED > Phone: +7 914 8 820 815 (irkutsk) > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From donpedrothird@REDACTED Thu Oct 24 11:23:06 2013 From: donpedrothird@REDACTED (Evgeny M) Date: Thu, 24 Oct 2013 02:23:06 -0700 (PDT) Subject: [erlang-questions] Old and new crypto: sign, rsa_sign, verify, rsa_verify compatibility In-Reply-To: References: Message-ID: Followup I can't even verify rsa signature created with the new sign(rsa,...) function. verify(rsa, ...) returns always false. No problems with old functions such as rsa_sign/rsa_verify. What am I doing wrong, could somebody help me? PrivateKey = [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>,<<0,0,0,64,104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57,194,30,29,119,116,166,32,71,194,252,162,197,193,144,84,98,223,170,137,84,25,86,2,237,128,201,216,139,98,173,122,229,3,62,100,69,241,18,186,249,170,25,156,172,32,228,180,129>>]. PublicKey = [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>]. Payload = <<"Launch the nukes.">>. Hash = crypto:hash(sha, Payload). Signature1 = crypto:sign(rsa, sha, {digest, Hash}, PrivateKey). crypto:verify(rsa, sha, {digest, Hash}, Signature1, PublicKey). %% false Signature2 = crypto:sign(rsa, sha, Payload, PrivateKey). crypto:verify(rsa, sha, Payload, Signature2, PublicKey). %% false SizedBinary = fun(Binary) -> <<(size(Binary)):32/integer, Binary/binary>> end. Signature3 = crypto:rsa_sign(SizedBinary(Hash), PrivateKey). crypto:rsa_verify(SizedBinary(Hash), SizedBinary(Signature3), PublicKey). %% true ???????, 24 ??????? 2013 ?., 3:07:51 UTC+4 ???????????? Evgeny M ???????: > > Hi, > > Is it possible to make RSA signatures compatible between old and new > crypto methods? I can't find a way how to do this. > Here's an example, run in R16B02: > > crypto:start(). > > %% these two keys are valid RSA keypair > PrivateKey = > [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>,<<0,0,0,64,104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57,194,30,29,119,116,166,32,71,194,252,162,197,193,144,84,98,223,170,137,84,25,86,2,237,128,201,216,139,98,173,122,229,3,62,100,69,241,18,186,249,170,25,156,172,32,228,180,129>>]. > PublicKey = > [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>]. > > SizedBinary = fun(Binary) -> <<(size(Binary)):32/integer, Binary/binary>> > end. > > Payload = <<"Launch the nukes.">>. > > Hash = crypto:sha(Payload). > > %%signed with old method > Signature = crypto:rsa_sign(SizedBinary(Hash), PrivateKey). > > %%verify with old method - returns true > crypto:rsa_verify(SizedBinary(Hash), SizedBinary(Signature), PublicKey). > > %%new method - returns false > crypto:verify(rsa, sha, {digest, Hash}, Signature, PublicKey). > > %%another try of new method - throws an 'bad argument' exception > crypto:verify(rsa, sha, {digest, SizedBinary(Hash)}, > SizedBinary(Signature), PublicKey). > > %%new method yet again - returns false > crypto:verify(rsa, sha, {digest, Hash}, SizedBinary(Signature), > PublicKey). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From askjuise@REDACTED Thu Oct 24 07:54:38 2013 From: askjuise@REDACTED (Alexander Petrovsky) Date: Thu, 24 Oct 2013 09:54:38 +0400 Subject: [erlang-questions] run strange behaviour In-Reply-To: <52686FF0.6080407@yahoo.com> References: <52686FF0.6080407@yahoo.com> Message-ID: Thanks a lot! How can I find out the number exhausted repetitions? 2013/10/24 Vyacheslav Levytskyy > Hello, > > According to 're' module documentation, "the quantifiers are "greedy", > that is, they match as much as possible (up to the maximum number of > permitted times)". This seems to be a problem with your case. The regex you > are using seems a bit problematic, forcing 're' to exhausting repetitions. > > As an option, you can use 'ungreedy' option, making only some of > quantifiers greedy via following them by "?". See for example: > re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo > (\\w(\\w+| )*) is a (\\w(\\w+?| )*?)">>, [ungreedy, global, {capture, > [1,3], binary}]). > {match,[[<<"bar">>, > <<"foo bar is a big yellow boat or sub">>]]} > > Best regards, > Vyacheslav Levytskyy > > > On 23.10.2013 22:26, Alexander Petrovsky wrote: > > Hi! > > I have the regex "^foo (\\w+(\\w* *)*) is an (\\w+(\\w* *)*)", and I get > strange behaviour when I do: > > 1> re:run(<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo > (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], > binary}]). > {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]} > > 2> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, > <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], > binary}]). > nomatch > > I tested this regexp in clojure and python: > > => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a foo > bar is a big yellow boat or") > ["foo bar is a foo bar is a big yellow boat or" "bar is a foo bar" "" "big > yellow boat or" ""] > > => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a foo > bar is a big yellow boat or sub") > ["foo bar is a foo bar is a big yellow boat or sub" "bar is a foo bar" "" > "big yellow boat or sub" ""] > > >>> import re > >>> p = re.compile('foo (\w+(\w* *)*) is a (\w+(\w* *)*)') > >>> p.match("foo bar is a foo bar is a big yellow boat or") > <_sre.SRE_Match object at 0x100293c00> > >>> p.match("foo bar is a foo bar is a big yellow boat or sub") > <_sre.SRE_Match object at 0x100293ab0> > > Can someone explain me, why I get on second string "foo bar is a foo bar > is a big yellow boat or sub" nomatch? This is a bug? > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Jabber: juise@REDACTED > Phone: +7 914 8 820 815 (irkutsk) > > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > > -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Jabber: juise@REDACTED Phone: +7 914 8 820 815 (irkutsk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Thu Oct 24 15:07:01 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 24 Oct 2013 09:07:01 -0400 Subject: [erlang-questions] Distributed Erlang transport over SSL In-Reply-To: References: Message-ID: I've been experimenting with starting Erlang distribution with both TLS and TCP distributed transports as the "-proto_dist" option allows to specify multiple modules handling distributed transport setup, but stumbled across the fact that when both inet_tls and inet_tcp is specified, it fails to register the second transport with EPMD. I think the answer is no, but is there a way to tell EPMD that the same node can have more than one port registered for a given node per protocol it supports? If it's not possible, maybe I would need to roll out a custom distributed transport handling module that would conditionally upgrade the incoming connection from TCP to SSL based on some user-logic (e.g. if a node doesn't belong to a local cluster). Has anyone done anything similar? On Mon, Oct 21, 2013 at 12:39 PM, Motiejus Jak?tys wrote: > On Mon, Oct 21, 2013 at 5:56 PM, Serge Aleynikov > wrote: > > seem to be any documentation of if it's possible to give hints to a given > > node to use transport alternative to the one used by current node at > startup > > when connecting to given nodes. > > > > If this is not supported, I would opt for this feature request as this > seems > > to be a very general case when running node configurations spanning > multiple > > clusters. > > Hi, > > See Patrick Nyblon's reply to a similar question: > http://erlang.org/pipermail/erlang-questions/2012-October/069876.html > > From the last paragraph I infer that what you are trying to do is > supported or easily supportable (lacks details though). > > -- > Motiejus Jak?tys > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Thu Oct 24 15:36:51 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Thu, 24 Oct 2013 15:36:51 +0200 Subject: [erlang-questions] run strange behaviour In-Reply-To: <52686FF0.6080407@yahoo.com> References: <52686FF0.6080407@yahoo.com> Message-ID: Being greedy or not shouldn't change whether the regex matches or not. I believe the issue is something else...: It's bad practise to have repetitions of something that matches the empty string - such as (\w* *)* - because that could be repeated any number of times. Indeed, the original regex runs pretty slowly: 8> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], binary}]]). {1052818, {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]}} My guess, therefore, is that the regexp times out/reaches some run-duration limit on the longer input string. Fixing the regex to not have repetitions of something that matches "" helps both the run time: 9> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo (\\w+ *(\\w+ *)*) is a (\\w+ *(\\w+ *)*)">>, [global, {capture, [1,3], binary}]]). {14315, {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]}} % 74x faster :-) and the result for the longer input string: 10> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo (\\w+ *(\\w+ *)*) is a (\\w+ *(\\w+ *)*)">>, [global, {capture, [1,3], binary}]]). {49911, {match,[[<<"bar is a foo bar">>, <<"big yellow boat or sub">>]]}} /Erik 2013/10/24 Vyacheslav Levytskyy > Hello, > > According to 're' module documentation, "the quantifiers are "greedy", > that is, they match as much as possible (up to the maximum number of > permitted times)". This seems to be a problem with your case. The regex you > are using seems a bit problematic, forcing 're' to exhausting repetitions. > > As an option, you can use 'ungreedy' option, making only some of > quantifiers greedy via following them by "?". See for example: > re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo > (\\w(\\w+| )*) is a (\\w(\\w+?| )*?)">>, [ungreedy, global, {capture, > [1,3], binary}]). > {match,[[<<"bar">>, > <<"foo bar is a big yellow boat or sub">>]]} > > Best regards, > Vyacheslav Levytskyy > > > On 23.10.2013 22:26, Alexander Petrovsky wrote: > > Hi! > > I have the regex "^foo (\\w+(\\w* *)*) is an (\\w+(\\w* *)*)", and I get > strange behaviour when I do: > > 1> re:run(<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo > (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], > binary}]). > {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]} > > 2> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, > <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], > binary}]). > nomatch > > I tested this regexp in clojure and python: > > => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a foo > bar is a big yellow boat or") > ["foo bar is a foo bar is a big yellow boat or" "bar is a foo bar" "" "big > yellow boat or" ""] > > => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a foo > bar is a big yellow boat or sub") > ["foo bar is a foo bar is a big yellow boat or sub" "bar is a foo bar" "" > "big yellow boat or sub" ""] > > >>> import re > >>> p = re.compile('foo (\w+(\w* *)*) is a (\w+(\w* *)*)') > >>> p.match("foo bar is a foo bar is a big yellow boat or") > <_sre.SRE_Match object at 0x100293c00> > >>> p.match("foo bar is a foo bar is a big yellow boat or sub") > <_sre.SRE_Match object at 0x100293ab0> > > Can someone explain me, why I get on second string "foo bar is a foo bar > is a big yellow boat or sub" nomatch? This is a bug? > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Jabber: juise@REDACTED > Phone: +7 914 8 820 815 (irkutsk) > > > > _______________________________________________ > 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 serge@REDACTED Thu Oct 24 15:58:28 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 24 Oct 2013 09:58:28 -0400 Subject: [erlang-questions] Distributed Erlang transport over SSL In-Reply-To: References: Message-ID: Commenting on my own question. According to this documentation: http://erlang.org/doc/apps/erts/erl_dist_protocol.html the PORT_PLEASE2_REQ (122) query doesn't allow the caller to specify the protocol of interest. Note that epmd's ALIVE2_REQ (120) request does support specification of a protocol for the registered node (though I couldn't find any mapping of a byte to protocol type, except for 0 being TCP), but the erts/epmd/src/epmd_srv.c:1209 loop only does "uniqueness" check by name and doesn't perform the protocol match. I propose extending the EPMD specification to be able to register more than one protocol per node, and to be able to query EPMD either by name only or by {Name, Protocol}. When a node is queried by name, the implementation should default to the first registered protocol. If there's a consensus that this functionality is acceptable, I can submit a patch. Serge On Thu, Oct 24, 2013 at 9:07 AM, Serge Aleynikov wrote: > I've been experimenting with starting Erlang distribution with both TLS > and TCP distributed transports as the "-proto_dist" option allows to > specify multiple modules handling distributed transport setup, but stumbled > across the fact that when both inet_tls and inet_tcp is specified, it fails > to register the second transport with EPMD. > > I think the answer is no, but is there a way to tell EPMD that the same > node can have more than one port registered for a given node per protocol > it supports? > > If it's not possible, maybe I would need to roll out a custom distributed > transport handling module that would conditionally upgrade the incoming > connection from TCP to SSL based on some user-logic (e.g. if a node doesn't > belong to a local cluster). Has anyone done anything similar? > > > On Mon, Oct 21, 2013 at 12:39 PM, Motiejus Jak?tys wrote: > >> On Mon, Oct 21, 2013 at 5:56 PM, Serge Aleynikov >> wrote: >> > seem to be any documentation of if it's possible to give hints to a >> given >> > node to use transport alternative to the one used by current node at >> startup >> > when connecting to given nodes. >> > >> > If this is not supported, I would opt for this feature request as this >> seems >> > to be a very general case when running node configurations spanning >> multiple >> > clusters. >> >> Hi, >> >> See Patrick Nyblon's reply to a similar question: >> http://erlang.org/pipermail/erlang-questions/2012-October/069876.html >> >> From the last paragraph I infer that what you are trying to do is >> supported or easily supportable (lacks details though). >> >> -- >> Motiejus Jak?tys >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From askjuise@REDACTED Thu Oct 24 18:01:38 2013 From: askjuise@REDACTED (Alexander Petrovsky) Date: Thu, 24 Oct 2013 20:01:38 +0400 Subject: [erlang-questions] run strange behaviour In-Reply-To: <526928A5.3090800@yahoo.com> References: <52686FF0.6080407@yahoo.com> <526928A5.3090800@yahoo.com> Message-ID: Thanks for explain. 2013/10/24 Vyacheslav Levytskyy > Agree, it is similar to what I have written, the initial regex was the > problem. It is not so important what is the number of the limit, from > documentation we know that it exists ("maximum number of permitted times"), > and anyway it is the regex what should be fixed. > > Vyacheslav > > > On 24.10.2013 16:36, Erik S?e S?rensen wrote: > > Being greedy or not shouldn't change whether the regex matches or not. > I believe the issue is something else...: > It's bad practise to have repetitions of something that matches the empty > string - such as (\w* *)* - because that could be repeated any number of > times. > Indeed, the original regex runs pretty slowly: > > 8> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat or">>, > <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], > binary}]]). > {1052818, > {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]}} > > My guess, therefore, is that the regexp times out/reaches some > run-duration limit on the longer input string. > > Fixing the regex to not have repetitions of something that matches "" > helps both the run time: > > 9> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat or">>, > <<"^foo (\\w+ *(\\w+ *)*) is a (\\w+ *(\\w+ *)*)">>, [global, {capture, > [1,3], binary}]]). > {14315, > {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]}} > % 74x faster :-) > > and the result for the longer input string: > > 10> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat or > sub">>, <<"^foo (\\w+ *(\\w+ *)*) is a (\\w+ *(\\w+ *)*)">>, [global, > {capture, [1,3], binary}]]). > {49911, > {match,[[<<"bar is a foo bar">>, > <<"big yellow boat or sub">>]]}} > > It is good results. BTW I find more efficient regex: 1> timer:tc(fun() -> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo (\\w+(\\w| )*) is a (\\w+(\\w| )*)$">>, [global, {capture, [1,3], binary}]) end). {27190, {match,[[<<"bar is a foo bar">>, <<"big yellow boat or sub">>]]}} 2> timer:tc(fun() -> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo (\\w+(\\w| )*) is a (\\w+(\\w| )*)$">>, [global, {capture, [1,3], binary}]) end). {143, {match,[[<<"bar is a foo bar">>, <<"big yellow boat or sub">>]]}} 3> timer:tc(fun() -> re:run(<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo (\\w+(\\w| )*) is a (\\w+(\\w| )*)$">>, [global, {capture, [1,3], binary}]) end). {138, {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]} > > /Erik > > > 2013/10/24 Vyacheslav Levytskyy > >> Hello, >> >> According to 're' module documentation, "the quantifiers are "greedy", >> that is, they match as much as possible (up to the maximum number of >> permitted times)". This seems to be a problem with your case. The regex you >> are using seems a bit problematic, forcing 're' to exhausting repetitions. >> >> As an option, you can use 'ungreedy' option, making only some of >> quantifiers greedy via following them by "?". See for example: >> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, <<"^foo >> (\\w(\\w+| )*) is a (\\w(\\w+?| )*?)">>, [ungreedy, global, {capture, >> [1,3], binary}]). >> {match,[[<<"bar">>, >> <<"foo bar is a big yellow boat or sub">>]]} >> >> Best regards, >> Vyacheslav Levytskyy >> >> >> On 23.10.2013 22:26, Alexander Petrovsky wrote: >> >> Hi! >> >> I have the regex "^foo (\\w+(\\w* *)*) is an (\\w+(\\w* *)*)", and I >> get strange behaviour when I do: >> >> 1> re:run(<<"foo bar is a foo bar is a big yellow boat or">>, <<"^foo >> (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], >> binary}]). >> {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]} >> >> 2> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, >> <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, {capture, [1,3], >> binary}]). >> nomatch >> >> I tested this regexp in clojure and python: >> >> => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a >> foo bar is a big yellow boat or") >> ["foo bar is a foo bar is a big yellow boat or" "bar is a foo bar" "" >> "big yellow boat or" ""] >> >> => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar is a >> foo bar is a big yellow boat or sub") >> ["foo bar is a foo bar is a big yellow boat or sub" "bar is a foo bar" "" >> "big yellow boat or sub" ""] >> >> >>> import re >> >>> p = re.compile('foo (\w+(\w* *)*) is a (\w+(\w* *)*)') >> >>> p.match("foo bar is a foo bar is a big yellow boat or") >> <_sre.SRE_Match object at 0x100293c00> >> >>> p.match("foo bar is a foo bar is a big yellow boat or sub") >> <_sre.SRE_Match object at 0x100293ab0> >> >> Can someone explain me, why I get on second string "foo bar is a foo >> bar is a big yellow boat or sub" nomatch? This is a bug? >> >> >> -- >> ?????????? ????????? / Alexander Petrovsky, >> >> Skype: askjuise >> Jabber: juise@REDACTED >> Phone: +7 914 8 820 815 <%2B7%20914%208%20820%20815> (irkutsk) >> >> >> >> _______________________________________________ >> 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 >> >> > > -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Jabber: juise@REDACTED Phone: +7 914 8 820 815 (irkutsk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.levytskyy@REDACTED Thu Oct 24 16:03:17 2013 From: v.levytskyy@REDACTED (Vyacheslav Levytskyy) Date: Thu, 24 Oct 2013 17:03:17 +0300 Subject: [erlang-questions] run strange behaviour In-Reply-To: References: <52686FF0.6080407@yahoo.com> Message-ID: <526928A5.3090800@yahoo.com> Agree, it is similar to what I have written, the initial regex was the problem. It is not so important what is the number of the limit, from documentation we know that it exists ("maximum number of permitted times"), and anyway it is the regex what should be fixed. Vyacheslav On 24.10.2013 16:36, Erik S?e S?rensen wrote: > Being greedy or not shouldn't change whether the regex matches or not. > I believe the issue is something else...: > It's bad practise to have repetitions of something that matches the > empty string - such as (\w* *)* - because that could be repeated any > number of times. > Indeed, the original regex runs pretty slowly: > > 8> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat > or">>, <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, > {capture, [1,3], binary}]]). > {1052818, > {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]}} > > My guess, therefore, is that the regexp times out/reaches some > run-duration limit on the longer input string. > > Fixing the regex to not have repetitions of something that matches "" > helps both the run time: > > 9> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat > or">>, <<"^foo (\\w+ *(\\w+ *)*) is a (\\w+ *(\\w+ *)*)">>, [global, > {capture, [1,3], binary}]]). > {14315, > {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]}} > % 74x faster :-) > > and the result for the longer input string: > > 10> timer:tc(re, run, [<<"foo bar is a foo bar is a big yellow boat or > sub">>, <<"^foo (\\w+ *(\\w+ *)*) is a (\\w+ *(\\w+ *)*)">>, [global, > {capture, [1,3], binary}]]). > {49911, > {match,[[<<"bar is a foo bar">>, > <<"big yellow boat or sub">>]]}} > > /Erik > > > 2013/10/24 Vyacheslav Levytskyy > > > Hello, > > According to 're' module documentation, "the quantifiers are > "greedy", that is, they match as much as possible (up to the > maximum number of permitted times)". This seems to be a problem > with your case. The regex you are using seems a bit problematic, > forcing 're' to exhausting repetitions. > > As an option, you can use 'ungreedy' option, making only some of > quantifiers greedy via following them by "?". See for example: > re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, > <<"^foo (\\w(\\w+| )*) is a (\\w(\\w+?| )*?)">>, [ungreedy, > global, {capture, [1,3], binary}]). > {match,[[<<"bar">>, > <<"foo bar is a big yellow boat or sub">>]]} > > Best regards, > Vyacheslav Levytskyy > > > On 23.10.2013 22:26, Alexander Petrovsky wrote: >> Hi! >> >> I have the regex "^foo (\\w+(\\w* *)*) is an (\\w+(\\w* *)*)", >> and I get strange behaviour when I do: >> >> 1> re:run(<<"foo bar is a foo bar is a big yellow boat or">>, >> <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, >> {capture, [1,3], binary}]). >> {match,[[<<"bar is a foo bar">>,<<"big yellow boat or">>]]} >> >> 2> re:run(<<"foo bar is a foo bar is a big yellow boat or sub">>, >> <<"^foo (\\w+(\\w* *)*) is a (\\w+(\\w* *)*)">>, [global, >> {capture, [1,3], binary}]). >> nomatch >> >> I tested this regexp in clojure and python: >> >> => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar >> is a foo bar is a big yellow boat or") >> ["foo bar is a foo bar is a big yellow boat or" "bar is a foo >> bar" "" "big yellow boat or" ""] >> >> => (re-matches #"foo (\w+(\w* *)*) is a (\w+(\w* *)*)" "foo bar >> is a foo bar is a big yellow boat or sub") >> ["foo bar is a foo bar is a big yellow boat or sub" "bar is a foo >> bar" "" "big yellow boat or sub" ""] >> >> >>> import re >> >>> p = re.compile('foo (\w+(\w* *)*) is a (\w+(\w* *)*)') >> >>> p.match("foo bar is a foo bar is a big yellow boat or") >> <_sre.SRE_Match object at 0x100293c00> >> >>> p.match("foo bar is a foo bar is a big yellow boat or sub") >> <_sre.SRE_Match object at 0x100293ab0> >> >> Can someone explain me, why I get on second string "foo bar is a >> foo bar is a big yellow boat or sub" nomatch? This is a bug? >> >> >> -- >> ?????????? ????????? / Alexander Petrovsky, >> >> Skype: askjuise >> Jabber: juise@REDACTED >> Phone: +7 914 8 820 815 (irkutsk) >> >> >> >> _______________________________________________ >> 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 devin.butterfield@REDACTED Thu Oct 24 18:55:26 2013 From: devin.butterfield@REDACTED (Devin Butterfield) Date: Thu, 24 Oct 2013 09:55:26 -0700 Subject: [erlang-questions] running tests with ct_run (cross target environment) Message-ID: Hi, I am porting OTP to an embedded platform and trying to run standard OTP tests on target. I am new to erlang, so apologies is this a FAQ, though I have not found any explanation on the web. I've tried running directly using ct_run and also erlexec, but the results are the same: "Error detected: "Failed to start CTH, see the CT Log for details"". Looking at the log reveal *no* details about this failure. What am I missing? See below for output... Thanks! -- Regards, Devin Using erlexec command: ###################### # using erlexec ###################### root:/opt/myrel/tests/test_server> erlexec -sname test_server -rsh rsh -env PATH "/opt/myrel/tests/emulator_test:/sbin:/usr/sbin:/bin:/usr/bin:/opt/myrel/bin:/opt/myrel/erts-5.10.3/bin" -boot start_sasl -sasl errlog_type error -pz "/opt/ myrel/tests/test_server" -ct_test_vars "{net_dir,\"\"}" -eval "ts_run:ct_run_test(\"/opt/myrel/tests/emulator_test\", [{suite,float_SUITE},{logdir,\"../test_server\"},{auto_compile, false},{config,[\"../test_server/ts.config\",\"../test_server/ts.unix.config\"]},{vars,[{verbose,0}]},batch,{scale_timetraps,true}])" -noinput -s erlang halt Common Test starting (cwd is /opt/myrel/tests/emulator_test) CWD set to: "/opt/myrel/tests/test_server/ct_run.test_server@REDACTED " TEST INFO: 1 test(s), 12 case(s) in 1 suite(s) Testing tests.emulator_test.float_SUITE: Starting test, 12 test cases - - - - - - - - - - - - - - - - - - - - - - - - - - Error detected: "Failed to start CTH, see the CT Log for details" - - - - - - - - - - - - - - - - - - - - - - - - - - Testing tests.emulator_test.float_SUITE: *** FAILED *** init_per_suite Testing tests.emulator_test.float_SUITE: TEST COMPLETE, 0 ok, 0 failed, 12 skipped of 12 test cases Crash dump was written to: erl_crash.dump ################### # USING c_run ################### root:/opt/myrel/tests/test_server> ct_run -no_auto_compile -suite ../emulator_test/float_SUITE =PROGRESS REPORT==== 24-Mar-2035::03:29:17 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.40.0>}, {name,alarm_handler}, {mfargs,{alarm_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.41.0>}, {name,overload}, {mfargs,{overload,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === supervisor: {local,sasl_sup} started: [{pid,<0.39.0>}, {name,sasl_safe_sup}, {mfargs, {supervisor,start_link, [{local,sasl_safe_sup},sasl,safe]}}, {restart_type,permanent}, {shutdown,infinity}, {child_type,supervisor}] =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === supervisor: {local,sasl_sup} started: [{pid,<0.42.0>}, {name,release_handler}, {mfargs,{release_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === application: sasl started_at: ct@REDACTED Common Test v1.7.3 starting (cwd is /opt/myrel/tests/test_server) Eshell V5.10.3 (abort with ^G) (ct@REDACTED)1> (ct@REDACTED)1> CWD set to: "/opt/myrel/tests/test_server/ct_run.ct@REDACTED" (ct@REDACTED)1> TEST INFO: 1 test(s), 12 case(s) in 1 suite(s) (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: Starting test, 12 test cases (ct@REDACTED)1> - - - - - - - - - - - - - - - - - - - - - - - - - - Error detected: "Failed to start CTH, see the CT Log for details" - - - - - - - - - - - - - - - - - - - - - - - - - - (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: *** FAILED *** init_per_suite (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: TEST COMPLETE, 0 ok, 0 failed, 12 skipped of 12 test cases (ct@REDACTED)1> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Oct 24 23:47:52 2013 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 24 Oct 2013 23:47:52 +0200 Subject: [erlang-questions] running tests with ct_run (cross target environment) In-Reply-To: References: Message-ID: Hello Devin, The recommended way to run the Erlang/OTP tests is to use ts as described in the testing howto[1]. If you want to do the testing with ct_run or erlexec you have to setup some of the environment manually. In your case the Erlang VM cannot find the module ts_install_cth. This is a Common Test Hook needed by most OTP test suites to run. In the init_per_suite log you should have seen something like this: *** CT 2013-10-24 23:42:25.116 *** Suite Hook Failed to start a CTH: error:{undef, [{ts_install_cth,init, [#Ref<0.0.0.1380>,[]], []}, {ct_hooks,call_init,3, [{file,"ct_hooks.erl"},{line,147}]}, {ct_hooks,call,4, [{file,"ct_hooks.erl"},{line,222}]}, {ct_hooks,call,4, [{file,"ct_hooks.erl"},{line,209}]}, {ct_hooks,call,3, [{file,"ct_hooks.erl"},{line,183}]}, {ct_framework,ct_suite_init,3, [{file,"ct_framework.erl"},{line,262}]}, {test_server_sup,framework_call,4, [{file,"test_server_sup.erl"}, {line,511}]}, {test_server,run_test_case_eval,9, [{file,"test_server.erl"}, {line,1120}]}]} To make ct_run find that module you just have to add it to the path: ct_run -pa /opt/myrel/tests/test_server/ -no_auto_compile -suite ../emulator_test/float_SUITE Lukas On Thu, Oct 24, 2013 at 6:55 PM, Devin Butterfield < devin.butterfield@REDACTED> wrote: > Hi, > > I am porting OTP to an embedded platform and trying to run standard OTP > tests on target. I am new to erlang, so apologies is this a FAQ, though I > have not found any explanation on the web. I've tried running directly > using ct_run and also erlexec, but the results are the same: "Error > detected: "Failed to start CTH, see the CT Log for details"". Looking at > the log reveal *no* details about this failure. What am I missing? See > below for output... > > Thanks! > -- > Regards, Devin > > Using erlexec command: > > ###################### > # using erlexec > ###################### > > root:/opt/myrel/tests/test_server> erlexec -sname test_server -rsh rsh > -env PATH > "/opt/myrel/tests/emulator_test:/sbin:/usr/sbin:/bin:/usr/bin:/opt/myrel/bin:/opt/myrel/erts-5.10.3/bin" > -boot start_sasl -sasl errlog_type error -pz "/opt/ > myrel/tests/test_server" -ct_test_vars "{net_dir,\"\"}" -eval > "ts_run:ct_run_test(\"/opt/myrel/tests/emulator_test\", > [{suite,float_SUITE},{logdir,\"../test_server\"},{auto_compile, > false},{config,[\"../test_server/ts.config\",\"../test_server/ts.unix.config\"]},{vars,[{verbose,0}]},batch,{scale_timetraps,true}])" > -noinput -s erlang halt > > Common Test starting (cwd is /opt/myrel/tests/emulator_test) > > CWD set to: > "/opt/myrel/tests/test_server/ct_run.test_server@REDACTED > " > > TEST INFO: 1 test(s), 12 case(s) in 1 suite(s) > > Testing tests.emulator_test.float_SUITE: Starting test, 12 test cases > > - - - - - - - - - - - - - - - - - - - - - - - - - - > Error detected: "Failed to start CTH, see the CT Log for details" > - - - - - - - - - - - - - - - - - - - - - - - - - - > > Testing tests.emulator_test.float_SUITE: *** FAILED *** init_per_suite > Testing tests.emulator_test.float_SUITE: TEST COMPLETE, 0 ok, 0 failed, 12 > skipped of 12 test cases > > > Crash dump was written to: erl_crash.dump > > > ################### > # USING c_run > ################### > > > root:/opt/myrel/tests/test_server> ct_run -no_auto_compile -suite > ../emulator_test/float_SUITE > > =PROGRESS REPORT==== 24-Mar-2035::03:29:17 === > supervisor: {local,sasl_safe_sup} > started: [{pid,<0.40.0>}, > {name,alarm_handler}, > {mfargs,{alarm_handler,start_link,[]}}, > {restart_type,permanent}, > {shutdown,2000}, > {child_type,worker}] > > =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === > supervisor: {local,sasl_safe_sup} > started: [{pid,<0.41.0>}, > {name,overload}, > {mfargs,{overload,start_link,[]}}, > {restart_type,permanent}, > {shutdown,2000}, > {child_type,worker}] > > =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === > supervisor: {local,sasl_sup} > started: [{pid,<0.39.0>}, > {name,sasl_safe_sup}, > {mfargs, > {supervisor,start_link, > [{local,sasl_safe_sup},sasl,safe]}}, > {restart_type,permanent}, > {shutdown,infinity}, > {child_type,supervisor}] > > =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === > supervisor: {local,sasl_sup} > started: [{pid,<0.42.0>}, > {name,release_handler}, > {mfargs,{release_handler,start_link,[]}}, > {restart_type,permanent}, > {shutdown,2000}, > {child_type,worker}] > > =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === > application: sasl > started_at: ct@REDACTED > > > Common Test v1.7.3 starting (cwd is /opt/myrel/tests/test_server) > > Eshell V5.10.3 (abort with ^G) > (ct@REDACTED)1> > (ct@REDACTED)1> > CWD set to: > "/opt/myrel/tests/test_server/ct_run.ct@REDACTED" > (ct@REDACTED)1> > TEST INFO: 1 test(s), 12 case(s) in 1 suite(s) > > (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: Starting test, > 12 test cases > (ct@REDACTED)1> > - - - - - - - - - - - - - - - - - - - - - - - - - - > Error detected: "Failed to start CTH, see the CT Log for details" > - - - - - - - - - - - - - - - - - - - - - - - - - - > > (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: *** FAILED *** > init_per_suite > (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: TEST COMPLETE, > 0 ok, 0 failed, 12 skipped of 12 test cases > > (ct@REDACTED)1> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Fri Oct 25 13:28:01 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 25 Oct 2013 13:28:01 +0200 Subject: [erlang-questions] Old and new crypto: sign, rsa_sign, verify, rsa_verify compatibility In-Reply-To: References: Message-ID: Hi! The new API does not want any "mpint" values (binaries with size tags) . If you try inputing the data according to the new API it will work much better. 1> PrivateKey = [<<2,1>>,<<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>, 1> <<104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57,194,30,29,119,116,166,32,71,194,252,162,197,193,144,84,98,223,170,137,84,25,86,2,237,128,201,216,139,98,173,122,229,3,62,100,69,241,18,186,249,170,25,156,172,32,228,180,129>>]. [<<2,1>>, <<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164, 221,80,251,171,85,16,134,227,199,246,113,...>>, <<104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57, 194,30,29,119,116,166,32,71,194,252,...>>] 2> 2> PublicKey = [<<2,1>>,<<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>]. [<<2,1>>, <<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164, 221,80,251,171,85,16,134,227,199,246,113,...>>] 3> Payload = <<"Launch the nukes.">>. <<"Launch the nukes.">> 4> Hash = crypto:hash(sha, Payload). <<241,220,196,57,84,10,43,93,89,232,208,46,247,79,76,207, 109,47,141,175>> 5> Signature1 = crypto:sign(rsa, sha, {digest, Hash}, PrivateKey). <<190,229,211,137,209,154,2,175,188,165,201,12,206,80,75, 148,11,78,207,14,214,170,105,252,63,128,61,191,217,...>> 6> 6> crypto:verify(rsa, sha, {digest, Hash}, Signature1, PublicKey). true Regards Ingela Erlang/OTP team - Ericsson AB 2013/10/24 John Doe > Hi, > > Is it possible to make RSA signatures compatible between old and new > crypto methods? I can't find a way how to do this. > Here's an example, run in R16B02: > > crypto:start(). > > %% these two keys are valid RSA keypair > PrivateKey = > [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>,<<0,0,0,64,104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57,194,30,29,119,116,166,32,71,194,252,162,197,193,144,84,98,223,170,137,84,25,86,2,237,128,201,216,139,98,173,122,229,3,62,100,69,241,18,186,249,170,25,156,172,32,228,180,129>>]. > PublicKey = > [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>]. > > SizedBinary = fun(Binary) -> <<(size(Binary)):32/integer, Binary/binary>> > end. > > Payload = <<"Launch the nukes.">>. > > Hash = crypto:sha(Payload). > > %%signed with old method > Signature = crypto:rsa_sign(SizedBinary(Hash), PrivateKey). > > %%verify with old method - returns true > crypto:rsa_verify(SizedBinary(Hash), SizedBinary(Signature), PublicKey). > > %%new method - returns false > crypto:verify(rsa, sha, {digest, Hash}, Signature, PublicKey). > > %%another try of new method - throws an 'bad argument' exception > crypto:verify(rsa, sha, {digest, SizedBinary(Hash)}, > SizedBinary(Signature), PublicKey). > > %%new method yet again - returns false > crypto:verify(rsa, sha, {digest, Hash}, SizedBinary(Signature), > PublicKey). > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From donpedrothird@REDACTED Fri Oct 25 14:05:16 2013 From: donpedrothird@REDACTED (Evgeny M) Date: Fri, 25 Oct 2013 05:05:16 -0700 (PDT) Subject: [erlang-questions] Old and new crypto: sign, rsa_sign, verify, rsa_verify compatibility In-Reply-To: References: Message-ID: Hi, Thank you, it works! ???????, 25 ??????? 2013 ?., 15:28:01 UTC+4 ???????????? Ingela Andin ???????: > > > Hi! > > The new API does not want any "mpint" values (binaries with size tags) . > If you try inputing the data according to the new API it will work much > better. > > 1> PrivateKey = > [<<2,1>>,<<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>, > 1> > <<104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57,194,30,29,119,116,166,32,71,194,252,162,197,193,144,84,98,223,170,137,84,25,86,2,237,128,201,216,139,98,173,122,229,3,62,100,69,241,18,186,249,170,25,156,172,32,228,180,129>>]. > [<<2,1>>, > <<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164, > 221,80,251,171,85,16,134,227,199,246,113,...>>, > <<104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57, > 194,30,29,119,116,166,32,71,194,252,...>>] > 2> > 2> PublicKey = > [<<2,1>>,<<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>]. > [<<2,1>>, > <<0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164, > 221,80,251,171,85,16,134,227,199,246,113,...>>] > 3> Payload = <<"Launch the nukes.">>. > <<"Launch the nukes.">> > 4> Hash = crypto:hash(sha, Payload). > <<241,220,196,57,84,10,43,93,89,232,208,46,247,79,76,207, > 109,47,141,175>> > 5> Signature1 = crypto:sign(rsa, sha, {digest, Hash}, PrivateKey). > <<190,229,211,137,209,154,2,175,188,165,201,12,206,80,75, > 148,11,78,207,14,214,170,105,252,63,128,61,191,217,...>> > 6> > 6> crypto:verify(rsa, sha, {digest, Hash}, Signature1, PublicKey). > true > > Regards Ingela Erlang/OTP team - Ericsson AB > > > 2013/10/24 John Doe > > >> Hi, >> >> Is it possible to make RSA signatures compatible between old and new >> crypto methods? I can't find a way how to do this. >> Here's an example, run in R16B02: >> >> crypto:start(). >> >> %% these two keys are valid RSA keypair >> PrivateKey = >> [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>,<<0,0,0,64,104,90,61,184,186,69,12,116,62,217,98,92,46,21,166,57,194,30,29,119,116,166,32,71,194,252,162,197,193,144,84,98,223,170,137,84,25,86,2,237,128,201,216,139,98,173,122,229,3,62,100,69,241,18,186,249,170,25,156,172,32,228,180,129>>]. >> PublicKey = >> [<<0,0,0,2,2,1>>,<<0,0,0,65,0,194,170,51,214,70,17,25,24,39,11,190,238,251,171,164,221,80,251,171,85,16,134,227,199,246,113,207,194,211,53,68,253,54,195,192,2,93,91,107,118,147,218,227,151,148,3,165,184,26,199,213,68,18,25,35,249,207,196,111,26,201,150,255,69>>]. >> >> SizedBinary = fun(Binary) -> <<(size(Binary)):32/integer, >> Binary/binary>> end. >> >> Payload = <<"Launch the nukes.">>. >> >> Hash = crypto:sha(Payload). >> >> %%signed with old method >> Signature = crypto:rsa_sign(SizedBinary(Hash), PrivateKey). >> >> %%verify with old method - returns true >> crypto:rsa_verify(SizedBinary(Hash), SizedBinary(Signature), PublicKey). >> >> %%new method - returns false >> crypto:verify(rsa, sha, {digest, Hash}, Signature, PublicKey). >> >> %%another try of new method - throws an 'bad argument' exception >> crypto:verify(rsa, sha, {digest, SizedBinary(Hash)}, >> SizedBinary(Signature), PublicKey). >> >> %%new method yet again - returns false >> crypto:verify(rsa, sha, {digest, Hash}, SizedBinary(Signature), >> PublicKey). >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergej.jurecko@REDACTED Fri Oct 25 17:43:22 2013 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Fri, 25 Oct 2013 17:43:22 +0200 Subject: [erlang-questions] ssl server multiple certificates Message-ID: hello, Is it possible to host multiple ssl certificates for different domains on a single IP and port? Like nginx is capable of doing. Sergej From devin.butterfield@REDACTED Fri Oct 25 17:53:36 2013 From: devin.butterfield@REDACTED (Devin Butterfield) Date: Fri, 25 Oct 2013 08:53:36 -0700 Subject: [erlang-questions] running tests with ct_run (cross target environment) In-Reply-To: References: Message-ID: Hi Lukas, Yes now I see -- I was looking in ctlog when I should have looked in the init_per_suite log. Adding -pa definitely fixes this issue. Thank you for your help! -- Regards, Devin On Thu, Oct 24, 2013 at 2:47 PM, Lukas Larsson wrote: > Hello Devin, > > The recommended way to run the Erlang/OTP tests is to use ts as described > in the testing howto[1]. > > If you want to do the testing with ct_run or erlexec you have to setup > some of the environment manually. > > In your case the Erlang VM cannot find the module ts_install_cth. This is > a Common Test Hook needed by most OTP test suites to run. In the > init_per_suite log you should have seen something like this: > > *** CT 2013-10-24 23:42:25.116 *** Suite Hook > Failed to start a CTH: error:{undef, > [{ts_install_cth,init, > [#Ref<0.0.0.1380>,[]], > []}, > {ct_hooks,call_init,3, > [{file,"ct_hooks.erl"},{line,147}]}, > {ct_hooks,call,4, > [{file,"ct_hooks.erl"},{line,222}]}, > {ct_hooks,call,4, > [{file,"ct_hooks.erl"},{line,209}]}, > {ct_hooks,call,3, > [{file,"ct_hooks.erl"},{line,183}]}, > {ct_framework,ct_suite_init,3, > > [{file,"ct_framework.erl"},{line,262}]}, > {test_server_sup,framework_call,4, > [{file,"test_server_sup.erl"}, > {line,511}]}, > {test_server,run_test_case_eval,9, > [{file,"test_server.erl"}, > {line,1120}]}]} > > To make ct_run find that module you just have to add it to the path: > > ct_run -pa /opt/myrel/tests/test_server/ -no_auto_compile -suite > ../emulator_test/float_SUITE > > Lukas > > > On Thu, Oct 24, 2013 at 6:55 PM, Devin Butterfield < > devin.butterfield@REDACTED> wrote: > >> Hi, >> >> I am porting OTP to an embedded platform and trying to run standard OTP >> tests on target. I am new to erlang, so apologies is this a FAQ, though I >> have not found any explanation on the web. I've tried running directly >> using ct_run and also erlexec, but the results are the same: "Error >> detected: "Failed to start CTH, see the CT Log for details"". Looking at >> the log reveal *no* details about this failure. What am I missing? See >> below for output... >> >> Thanks! >> -- >> Regards, Devin >> >> Using erlexec command: >> >> ###################### >> # using erlexec >> ###################### >> >> root:/opt/myrel/tests/test_server> erlexec -sname test_server -rsh rsh >> -env PATH >> "/opt/myrel/tests/emulator_test:/sbin:/usr/sbin:/bin:/usr/bin:/opt/myrel/bin:/opt/myrel/erts-5.10.3/bin" >> -boot start_sasl -sasl errlog_type error -pz "/opt/ >> myrel/tests/test_server" -ct_test_vars "{net_dir,\"\"}" -eval >> "ts_run:ct_run_test(\"/opt/myrel/tests/emulator_test\", >> [{suite,float_SUITE},{logdir,\"../test_server\"},{auto_compile, >> false},{config,[\"../test_server/ts.config\",\"../test_server/ts.unix.config\"]},{vars,[{verbose,0}]},batch,{scale_timetraps,true}])" >> -noinput -s erlang halt >> >> Common Test starting (cwd is /opt/myrel/tests/emulator_test) >> >> CWD set to: >> "/opt/myrel/tests/test_server/ct_run.test_server@REDACTED >> " >> >> TEST INFO: 1 test(s), 12 case(s) in 1 suite(s) >> >> Testing tests.emulator_test.float_SUITE: Starting test, 12 test cases >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - >> Error detected: "Failed to start CTH, see the CT Log for details" >> - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> Testing tests.emulator_test.float_SUITE: *** FAILED *** init_per_suite >> Testing tests.emulator_test.float_SUITE: TEST COMPLETE, 0 ok, 0 failed, >> 12 skipped of 12 test cases >> >> >> Crash dump was written to: erl_crash.dump >> >> >> ################### >> # USING c_run >> ################### >> >> >> root:/opt/myrel/tests/test_server> ct_run -no_auto_compile -suite >> ../emulator_test/float_SUITE >> >> =PROGRESS REPORT==== 24-Mar-2035::03:29:17 === >> supervisor: {local,sasl_safe_sup} >> started: [{pid,<0.40.0>}, >> {name,alarm_handler}, >> {mfargs,{alarm_handler,start_link,[]}}, >> {restart_type,permanent}, >> {shutdown,2000}, >> {child_type,worker}] >> >> =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === >> supervisor: {local,sasl_safe_sup} >> started: [{pid,<0.41.0>}, >> {name,overload}, >> {mfargs,{overload,start_link,[]}}, >> {restart_type,permanent}, >> {shutdown,2000}, >> {child_type,worker}] >> >> =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === >> supervisor: {local,sasl_sup} >> started: [{pid,<0.39.0>}, >> {name,sasl_safe_sup}, >> {mfargs, >> {supervisor,start_link, >> [{local,sasl_safe_sup},sasl,safe]}}, >> {restart_type,permanent}, >> {shutdown,infinity}, >> {child_type,supervisor}] >> >> =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === >> supervisor: {local,sasl_sup} >> started: [{pid,<0.42.0>}, >> {name,release_handler}, >> {mfargs,{release_handler,start_link,[]}}, >> {restart_type,permanent}, >> {shutdown,2000}, >> {child_type,worker}] >> >> =PROGRESS REPORT==== 24-Mar-2035::03:29:18 === >> application: sasl >> started_at: ct@REDACTED >> >> >> Common Test v1.7.3 starting (cwd is /opt/myrel/tests/test_server) >> >> Eshell V5.10.3 (abort with ^G) >> (ct@REDACTED)1> >> (ct@REDACTED)1> >> CWD set to: >> "/opt/myrel/tests/test_server/ct_run.ct@REDACTED" >> (ct@REDACTED)1> >> TEST INFO: 1 test(s), 12 case(s) in 1 suite(s) >> >> (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: Starting test, >> 12 test cases >> (ct@REDACTED)1> >> - - - - - - - - - - - - - - - - - - - - - - - - - - >> Error detected: "Failed to start CTH, see the CT Log for details" >> - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: *** FAILED *** >> init_per_suite >> (ct@REDACTED)1> Testing tests.emulator_test.float_SUITE: TEST COMPLETE, >> 0 ok, 0 failed, 12 skipped of 12 test cases >> >> (ct@REDACTED)1> >> >> >> _______________________________________________ >> 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 Fri Oct 25 18:37:45 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 25 Oct 2013 18:37:45 +0200 Subject: [erlang-questions] Maps branch and disclaimers Message-ID: <526A9E59.7090406@erlang.org> Hi! Here you go, Maps! I've pushed a Maps branch to Erlang/OTPs repository at GitHub. To get the branch, git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation or find it at https://github.com/erlang/otp/tree/egil/maps/eep-implementation I want to state the following so there is no room for uncertainty: - This branch contains a *development stage* of the *experimental* Maps feature for Erlang. This means: - Do not use it in production since it is not stable, - Do not base any git branch on this branch since it will most likely be rebased, - and finally, we reserve the right to change any API or interfaces to Maps currently implemented. The implementation is based on EEP 43 - Maps, see http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. _What is implemented?_ The maps module API and erlang guard BIFs as defined in the EEP are implemented. There are however some sematic mismatches with the EEP. I think those are where the definition contradict itself. For instance maps:is_key/1 compares with =:= as stated first in the definition but the later example uses lists:keymember which compares with ==. The syntax and all what that entails is implemented. The compiler will handle the map syntax and produce loadable beam-code. I believe this is what people want to test and is what I want people to test. Test the usability that is. I recommend people look at the EEP for information and also the testsuite located at erts/emulator/test/map_SUITE.erl for information on how to use Maps since no other documentation is available. Roughly, M0 = #{ key => Value1, "key" => Value2}, % for construction. M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates #{ "key" := V } = M1. % for matching Where the operator '=>' (assoc operator) is used for extending and creating new Maps and the operator ':=' is used to update existing key/values. The ':=' operator is the only operator allowed in patterns. I'm guessing some confusion will arise from these two types of operators on where you can and/or should use them. Look at the tests and EEP for details and inspiration. A major difference from the EEP are variables in keys. Variables in keys are not allowed at all. This is because we want to reduce the scope for this first stage. Plenty to do besides that. Here are some additional disclaimers to make people sad. _What is not implemented?_ - No variable keys. - No single value access. - No map comprehensions. - No datastructure to handle large Maps. - No MatchSpecs which uses the Maps syntax will work. _Known issues_ - Dialyzer will not work with maps in the code, this include PLT building with erts and stdlib. - HiPE, the native compiler, will not with maps code. - EDoc will not work with maps. I'm sure there are other issues as well, it is a development branch after all. =) I would also like to point out that no optimizations are done either with respect to the generated code. This means that the instruction set may change. We know of several optimization we want to do before R17, especially for the match compiler so keep that in mind. We will continue stabilizing the Maps implementation as we move forward towards R17 and take appropriate action depending on the feedback you give us. I would like to continue with saying a few words about possible changes that we are thinking about. _Variables in Keys_ This feature is actually furthest down on the work prio list. We want to stabilize the current features before moving forward and variable keys is the one most likely to be dropped if we get pressed for time. Meaning, it might not be implemented for R17 but instead implemented for R18. The plan right now is to keep it though. _The External Format_ The current external format /needs/ ordered keys as input for binary_to_term/1 and in distribution. This is of course an inconvinience when dealing with other language interfaces which has no idea of what the erlang term order is. I instead propose that the external format should handle unordered input of key-value pairs. The trade off is a more complicated decoding which will take longer. The distribution format should also be extended to be able cache keys. This is similar to the atom cache except we cache the entire key array for maps. This has been the intention all along but it not mentioned in the EEP. _Term order and sorting_ Finally the term order. This has been a sore point from the get go. Maps currently respects the Erlang term order for it's keys. The Erlang term order is what I call arithmetic term order. I propose that we extend Erlang with true term order where integer compares less then float, i.e. total term order. This would allowing newer ordered data structures, like maps, to be more useful. We don't have to take special care for the odd cases like keys 1.0 and 1 inhabiting the same slot in the data structure. gb_trees and such structures could also be extended to use this as those structures has the same limitations. With this type ordering we could have maps with this type of keys, #{ 1 => "integer", 1.0 => "float" } without causing confusion. I've been told that ETS ordered sets tables used to have this behaviour. Distinguishing between floats and integers. This was supposedly before the open source era, way back when dinosaurs roamed the planet .. I'm not clear on the details on why this behaviour was removed. Probably because of inconsistencies. For maps to work with this I only need two things. First, a compare operation in the runtime that can distinguish between floats and integers, very easy. Secondly, a BIF that sort a list of terms with this new compare operation which will be used in the compiler. But for completness, the following operators should also be implemented: =:= term exact equal to, already implemented =/= term not equal to, already implemented =:< term less or equal than >:= term greater or equal than <:< term less than >:> term greater than So, true = 1 <:< 1.0. I don't know prolog but perhaps these sematics should mimic prolog to respect Erlangs heritage. I have no strong opinion on this. This syntax would mimic the already present =:= and =/= relational operators hower this syntax is another topic and should be a seperate EEP. Happy testing! Regards, Bj?rn-Egil Dahlberg Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Oct 25 18:47:36 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 25 Oct 2013 18:47:36 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: <526AA0A8.8080507@ninenines.eu> Congratulations! Awesome job so far. On 10/25/2013 06:37 PM, Bj?rn-Egil Dahlberg wrote: > Hi! > > Here you go, Maps! > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > To get the branch, > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > or find it at > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > I want to state the following so there is no room for uncertainty: > - This branch contains a *development stage* of the *experimental* Maps > feature for Erlang. > > This means: > - Do not use it in production since it is not stable, > - Do not base any git branch on this branch since it will most likely > be rebased, > - and finally, we reserve the right to change any API or interfaces to > Maps currently implemented. > > The implementation is based on EEP 43 - Maps, see > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. > > _What is implemented?_ > > The maps module API and erlang guard BIFs as defined in the EEP are > implemented. There are however some sematic mismatches with the EEP. I > think those are where the definition contradict itself. For instance > maps:is_key/1 compares with =:= as stated first in the definition but > the later example uses lists:keymember which compares with ==. > > The syntax and all what that entails is implemented. The compiler will > handle the map syntax and produce loadable beam-code. I believe this is > what people want to test and is what I want people to test. Test the > usability that is. > > I recommend people look at the EEP for information and also the > testsuite located at erts/emulator/test/map_SUITE.erl for information on > how to use Maps since no other documentation is available. > > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > > Where the operator '=>' (assoc operator) is used for extending and > creating new Maps and the operator ':=' is used to update existing > key/values. The ':=' operator is the only operator allowed in patterns. > I'm guessing some confusion will arise from these two types of operators > on where you can and/or should use them. > > Look at the tests and EEP for details and inspiration. > > A major difference from the EEP are variables in keys. Variables in keys > are not allowed at all. This is because we want to reduce the scope for > this first stage. Plenty to do besides that. > > Here are some additional disclaimers to make people sad. > > _What is not implemented?_ > > - No variable keys. > - No single value access. > - No map comprehensions. > - No datastructure to handle large Maps. > - No MatchSpecs which uses the Maps syntax will work. > > _Known issues_ > > - Dialyzer will not work with maps in the code, this include PLT > building with erts and stdlib. > - HiPE, the native compiler, will not with maps code. > - EDoc will not work with maps. > > I'm sure there are other issues as well, it is a development branch > after all. =) > > I would also like to point out that no optimizations are done either > with respect to the generated code. This means that the instruction set > may change. We know of several optimization we want to do before R17, > especially for the match compiler so keep that in mind. > > We will continue stabilizing the Maps implementation as we move forward > towards R17 and take appropriate action depending on the feedback you > give us. > > I would like to continue with saying a few words about possible changes > that we are thinking about. > > _Variables in Keys_ > > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys > is the one most likely to be dropped if we get pressed for time. > Meaning, it might not be implemented for R17 but instead implemented for > R18. The plan right now is to keep it though. > > _The External Format_ > > The current external format /needs/ ordered keys as input for > binary_to_term/1 and in distribution. > > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I instead > propose that the external format should handle unordered input of > key-value pairs. The trade off is a more complicated decoding which will > take longer. > > The distribution format should also be extended to be able cache keys. > This is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all > along but it not mentioned in the EEP. > > _Term order and sorting_ > > Finally the term order. This has been a sore point from the get go. > > Maps currently respects the Erlang term order for it's keys. > > The Erlang term order is what I call arithmetic term order. I propose > that we extend Erlang with true term order where integer compares less > then float, i.e. total term order. > > This would allowing newer ordered data structures, like maps, to be more > useful. We don't have to take > special care for the odd cases like keys 1.0 and 1 inhabiting the same > slot in the data structure. gb_trees and such structures could also be > extended to use this as those structures has the same limitations. > > With this type ordering we could have maps with this type of keys, #{ 1 > => "integer", 1.0 => "float" } without causing confusion. > > I've been told that ETS ordered sets tables used to have this behaviour. > Distinguishing between floats and integers. This was supposedly before > the open source era, way back when dinosaurs roamed the planet .. I'm > not clear on the details on why this behaviour was removed. Probably > because of inconsistencies. > > For maps to work with this I only need two things. First, a compare > operation in the runtime that can distinguish between floats and > integers, very easy. Secondly, a BIF that sort a list of terms with this > new compare operation which will be used in the compiler. > > But for completness, the following operators should also be implemented: > > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > > So, true = 1 <:< 1.0. > > I don't know prolog but perhaps these sematics should mimic prolog to > respect Erlangs heritage. I have no strong opinion on this. > > This syntax would mimic the already present =:= and =/= relational > operators hower this syntax is another topic and should be a seperate EEP. > > Happy testing! > > Regards, > Bj?rn-Egil Dahlberg > Erlang/OTP > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From max.lapshin@REDACTED Fri Oct 25 20:06:40 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 25 Oct 2013 22:06:40 +0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526AA0A8.8080507@ninenines.eu> References: <526A9E59.7090406@erlang.org> <526AA0A8.8080507@ninenines.eu> Message-ID: Great! So, right now it may be used as a replacement for records in states? Records also doesn't allow variable keys. handle_info({tcp, Socket, Bin}, #{socket := Socket} = State) -> ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Oct 25 20:15:44 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 25 Oct 2013 14:15:44 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: <20131025181542.GG5671@ferdair.local> On 10/25, Bj?rn-Egil Dahlberg wrote: > > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > I assume you meant M2 = M1#... here? > > ... > > _The External Format_ > > The current external format /needs/ ordered keys as input for > binary_to_term/1 and in distribution. > > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I > instead propose that the external format should handle unordered > input of key-value pairs. The trade off is a more complicated > decoding which will take longer. > Could there be a flag in there that will allow to specify whether the terms are ordered or not? It sounds to me like this could yield the lowest cost for languages that *do* support sorting in manners similar to Erlang (most notably, other Erlang nodes), while having very little overhead for talking with other languages (where most of the time will be spent unserializing anyway). The flag could be ignored by languages unserializing the terms that do not understand/need Erlang's ordering, too, or optimize accordingly. > The distribution format should also be extended to be able cache > keys. This is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all > along but it not mentioned in the EEP. Shall the EEP be extended? > > _Term order and sorting_ > > > The Erlang term order is what I call arithmetic term order. I > propose that we extend Erlang with true term order where integer > compares less then float, i.e. total term order. > > ... > > But for completness, the following operators should also be implemented: > > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > Hell yes! I've found this extremely annoying for a long while. I could see the use of this, and it could be done without breaking backwards compatibility, except in some rare cases where it could be perceived as somewhat inconsistent (orddicts come to mind, where they use the arithmetic term order internally, but still enforce the true term order for keys -- and I can't see this being fixed) For what it's worth, Prolog's operators are @<, @=<, @>, @>=. I think that I would prefer your form, but someone with more clout on the matter (such as ROK) would be better placed than me to voice an opinion on this. Regards, Fred. From wallentin.dahlberg@REDACTED Fri Oct 25 20:24:56 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 25 Oct 2013 20:24:56 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <526AA0A8.8080507@ninenines.eu> Message-ID: 2013/10/25 Max Lapshin > Great! > > So, right now it may be used as a replacement for records in states? > Records also doesn't allow variable keys. > > > handle_info({tcp, Socket, Bin}, #{socket := Socket} = State) -> > ... > > Correct. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Fri Oct 25 20:42:26 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 25 Oct 2013 20:42:26 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <20131025181542.GG5671@ferdair.local> References: <526A9E59.7090406@erlang.org> <20131025181542.GG5671@ferdair.local> Message-ID: 2013/10/25 Fred Hebert > On 10/25, Bj?rn-Egil Dahlberg wrote: > > > > Roughly, > > M0 = #{ key => Value1, "key" => Value2}, % for construction. > > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > > #{ "key" := V } = M1. % for matching > > > > I assume you meant M2 = M1#... here? > Aww .. That's what I get for speeding through examples in mails. Yep, I screwed up the variables in the example .. =) > Value1 = a, Value2 = b, Value3 = c, Value4 = d. d > M0 = #{ key => Value1, "key" => Value2}. #{key => a,"key" => b} > M1 = M0#{ "key" := Value3, <<"key">> => Value4 }. #{key => a,"key" => c,<<"key">> => d} > #{ "key" := V } = M1, V. c That will work .. > > > > > > ... > > > > _The External Format_ > > > > The current external format /needs/ ordered keys as input for > > binary_to_term/1 and in distribution. > > > > This is of course an inconvinience when dealing with other language > > interfaces which has no idea of what the erlang term order is. I > > instead propose that the external format should handle unordered > > input of key-value pairs. The trade off is a more complicated > > decoding which will take longer. > > > > Could there be a flag in there that will allow to specify whether the > terms are ordered or not? It sounds to me like this could yield the > lowest cost for languages that *do* support sorting in manners similar > to Erlang (most notably, other Erlang nodes), while having very little > overhead for talking with other languages (where most of the time will > be spent unserializing anyway). > > The flag could be ignored by languages unserializing the terms that do > not understand/need Erlang's ordering, too, or optimize accordingly. > Erlang nodes, and all other nodes capable, will handle this like what we say below here (caching). The capability detection would be part of the negotiation when connecting. > > > The distribution format should also be extended to be able cache > > keys. This is similar to the atom cache except we > > cache the entire key array for maps. This has been the intention all > > along but it not mentioned in the EEP. > > Shall the EEP be extended? > Perhaps. I think this should be extended later on. I will wait for more input. > > > > > _Term order and sorting_ > > > > > > The Erlang term order is what I call arithmetic term order. I > > propose that we extend Erlang with true term order where integer > > compares less then float, i.e. total term order. > > > > ... > > > > But for completness, the following operators should also be implemented: > > > > =:= term exact equal to, already implemented > > =/= term not equal to, already implemented > > =:< term less or equal than > > >:= term greater or equal than > > <:< term less than > > >:> term greater than > > > > Hell yes! I've found this extremely annoying for a long while. I could > see the use of this, and it could be done without breaking backwards > compatibility, except in some rare cases where it could be perceived as > somewhat inconsistent (orddicts come to mind, where they use the > arithmetic term order internally, but still enforce the true term order > for keys -- and I can't see this being fixed) > Yoy \o/ Hopefully it is an inconsistency we can live with. I certainly thinks so. > > For what it's worth, Prolog's operators are @<, @=<, @>, @>=. I think > that I would prefer your form, but someone with more clout on the matter > (such as ROK) would be better placed than me to voice an opinion on > this. > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Fri Oct 25 23:51:11 2013 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Fri, 25 Oct 2013 14:51:11 -0700 Subject: [erlang-questions] file:write/2 blocking indefinitely Message-ID: <705406AE-EE71-4346-BE8F-FBAEF73FCF42@alumni.caltech.edu> Hi, I've been having this odd issue lately with a system. I have a file opened with file:open (File, [ write, raw, compressed ]) Held in a gen_server state, and send message which are then written to the file with file:write (FileHandle, Bytes) However, every so often, the file:write/2 call just stops working and essentially blocks. This causes the mailbox of the gen_server to slowly fill up and eventually the node runs out of memory. We currently work around this issue, but I'm wondering if anyone has seen this sort of thing before, or has any ideas around work arounds? I'm not sure if this is non-blocking call or not, if not is there an alternate file call which is non-blocking? Does compression cause additional issues? Is the fact that it's writing to an SSD have any bearing? The system is CentOS 5.4 Erlang R15B02 Thanks, -Anthony PS. The actual code is here in case anyone feels like a deeper look https://github.com/lwes/lwes-erlang/blob/master/src/lwes_journaller.erl -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.abrahamsson@REDACTED Sat Oct 26 01:53:04 2013 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Sat, 26 Oct 2013 01:53:04 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> (=?iso-8859-1?Q?=22Bj=F6rn-Egil?= Dahlberg"'s message of "Fri, 25 Oct 2013 18:37:45 +0200") References: <526A9E59.7090406@erlang.org> Message-ID: <82r4b8ewm7.fsf@assar.nollberga> > Here you go, Maps! > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. Hi, this is cool! I did some performance experiments with gpb, a google protobuf encoder/decoder, in which I had already implemented experimental support for maps. It seems map creation is fast! representation of msg records maps msg to binary: 27.6 MB/s 22.9 MB/s (83% of record speed) binary to msg: 27.3 MB/s 29.9 MB/s (110% of record speed) The figures are number of megabytes processed per second, so higher number means faster/better. The "binary to msg" involves creating a record or map, with several fields, once for each parsed message or sub message. The "msg to binary" uses a match for several message fields to assign each field to a variable, once for each message or sub message to encode. Included in these figures is of course also some binary processing. I also stumbled upon an what appears to be a compiler error. Given this program: -module(mapbug). -export([verify_msg/1]). verify_msg(Msg) -> v_msg_m1(Msg). v_msg_m1(#{f2 := F2}) -> if is_list(F2) -> [v_type_uint32(Elem) || Elem <- F2]; true -> ok end, ok; v_msg_m1(_X) -> ok. v_type_uint32(_N) -> ok. compiling it results in: 1> c("/path/to/mapbug", []). mapbug: function v_msg_m1/1+17: Internal consistency check failed - please report this bug. Instruction: return Error: {stack_frame,undecided}: error BRs Tomas From daniel.goertzen@REDACTED Sat Oct 26 04:22:19 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 25 Oct 2013 21:22:19 -0500 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: Works like a charm! Yamler (Erlang yaml file loader) now constructs yaml mappings as erlang maps. I updated the README examples to show these maps in action: https://github.com/goertzenator/yamler/tree/mapping_as_map Thanks for maps! Dan. On Fri, Oct 25, 2013 at 11:37 AM, Bj?rn-Egil Dahlberg wrote: > Hi! > > Here you go, Maps! > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > To get the branch, > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > or find it at > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > I want to state the following so there is no room for uncertainty: > - This branch contains a *development stage* of the *experimental* Maps > feature for Erlang. > > This means: > - Do not use it in production since it is not stable, > - Do not base any git branch on this branch since it will most likely be > rebased, > - and finally, we reserve the right to change any API or interfaces to > Maps currently implemented. > > The implementation is based on EEP 43 - Maps, see > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. > > *What is implemented?* > > The maps module API and erlang guard BIFs as defined in the EEP are > implemented. There are however some sematic mismatches with the EEP. I > think those are where the definition contradict itself. For instance > maps:is_key/1 compares with =:= as stated first in the definition but the > later example uses lists:keymember which compares with ==. > > The syntax and all what that entails is implemented. The compiler will > handle the map syntax and produce loadable beam-code. I believe this is > what people want to test and is what I want people to test. Test the > usability that is. > > I recommend people look at the EEP for information and also the testsuite > located at erts/emulator/test/map_SUITE.erl for information on how to use > Maps since no other documentation is available. > > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > > Where the operator '=>' (assoc operator) is used for extending and > creating new Maps and the operator ':=' is used to update existing > key/values. The ':=' operator is the only operator allowed in patterns. I'm > guessing some confusion will arise from these two types of operators on > where you can and/or should use them. > > Look at the tests and EEP for details and inspiration. > > A major difference from the EEP are variables in keys. Variables in keys > are not allowed at all. This is because we want to reduce the scope for > this first stage. Plenty to do besides that. > > Here are some additional disclaimers to make people sad. > > *What is not implemented?* > > - No variable keys. > - No single value access. > - No map comprehensions. > - No datastructure to handle large Maps. > - No MatchSpecs which uses the Maps syntax will work. > > *Known issues* > > - Dialyzer will not work with maps in the code, this include PLT building > with erts and stdlib. > - HiPE, the native compiler, will not with maps code. > - EDoc will not work with maps. > > I'm sure there are other issues as well, it is a development branch after > all. =) > > I would also like to point out that no optimizations are done either with > respect to the generated code. This means that the instruction set may > change. We know of several optimization we want to do before R17, > especially for the match compiler so keep that in mind. > > We will continue stabilizing the Maps implementation as we move forward > towards R17 and take appropriate action depending on the feedback you give > us. > > I would like to continue with saying a few words about possible changes > that we are thinking about. > > *Variables in Keys* > > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys is > the one most likely to be dropped if we get pressed for time. Meaning, it > might not be implemented for R17 but instead implemented for R18. The plan > right now is to keep it though. > > *The External Format* > > The current external format *needs* ordered keys as input for > binary_to_term/1 and in distribution. > > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I instead > propose that the external format should handle unordered input of key-value > pairs. The trade off is a more complicated decoding which will take longer. > > The distribution format should also be extended to be able cache keys. > This is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all along > but it not mentioned in the EEP. > > *Term order and sorting* > > Finally the term order. This has been a sore point from the get go. > > Maps currently respects the Erlang term order for it's keys. > > The Erlang term order is what I call arithmetic term order. I propose that > we extend Erlang with true term order where integer compares less then > float, i.e. total term order. > > This would allowing newer ordered data structures, like maps, to be more > useful. We don't have to take > special care for the odd cases like keys 1.0 and 1 inhabiting the same > slot in the data structure. gb_trees and such structures could also be > extended to use this as those structures has the same limitations. > > With this type ordering we could have maps with this type of keys, #{ 1 => > "integer", 1.0 => "float" } without causing confusion. > > I've been told that ETS ordered sets tables used to have this behaviour. > Distinguishing between floats and integers. This was supposedly before the > open source era, way back when dinosaurs roamed the planet .. I'm not clear > on the details on why this behaviour was removed. Probably because of > inconsistencies. > > For maps to work with this I only need two things. First, a compare > operation in the runtime that can distinguish between floats and integers, > very easy. Secondly, a BIF that sort a list of terms with this new compare > operation which will be used in the compiler. > > But for completness, the following operators should also be implemented: > > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > > So, true = 1 <:< 1.0. > > I don't know prolog but perhaps these sematics should mimic prolog to > respect Erlangs heritage. I have no strong opinion on this. > > This syntax would mimic the already present =:= and =/= relational > operators hower this syntax is another topic and should be a seperate EEP. > > Happy testing! > > Regards, > Bj?rn-Egil Dahlberg > Erlang/OTP > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Sat Oct 26 04:52:18 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Oct 2013 04:52:18 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <82r4b8ewm7.fsf@assar.nollberga> References: <526A9E59.7090406@erlang.org> <82r4b8ewm7.fsf@assar.nollberga> Message-ID: 2013/10/26 Tomas Abrahamsson > > > Here you go, Maps! > > > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > Hi, this is cool! > > I did some performance experiments with gpb, a google > protobuf encoder/decoder, in which I had already implemented > experimental support for maps. It seems map creation is fast! > > representation of msg > records maps > msg to binary: 27.6 MB/s 22.9 MB/s (83% of record speed) > binary to msg: 27.3 MB/s 29.9 MB/s (110% of record speed) > > The figures are number of megabytes processed per second, so > higher number means faster/better. The "binary to msg" involves > creating a record or map, with several fields, once for each > parsed message or sub message. The "msg to binary" uses a match > for several message fields to assign each field to a variable, > once for each message or sub message to encode. Included in > these figures is of course also some binary processing. > Oh, nice speed, even without any optimizations. =) > > > I also stumbled upon an what appears to be a compiler error. > Given this program: > > -module(mapbug). > -export([verify_msg/1]). > > verify_msg(Msg) -> > v_msg_m1(Msg). > > v_msg_m1(#{f2 := F2}) -> > if is_list(F2) -> [v_type_uint32(Elem) || Elem <- F2]; > true -> ok > end, > ok; > v_msg_m1(_X) -> > ok. > > v_type_uint32(_N) -> > ok. > I believe I found the bug. My attention is a bit split right now so I'm not completely sure .. watching Vancouver Canucks beat the Blues, and watching WCS Season 3. However I think the allocate stack above a fail label which may jump over a deallocate causes this problem. The following will solve the problem: diff --git a/lib/compiler/src/beam_block.erl b/lib/compiler/src/beam_block.erl index ed660ad..de455f7 100644 --- a/lib/compiler/src/beam_block.erl +++ b/lib/compiler/src/beam_block.erl @@ -227,6 +227,7 @@ move_allocates_2(Alloc, [], Acc) -> alloc_may_pass({set,_,_,{alloc,_,_}}) -> false; alloc_may_pass({set,_,_,{set_tuple_element,_}}) -> false; +alloc_may_pass({set,_,_,{get_map_element,_,_}}) -> false; alloc_may_pass({set,_,_,put_list}) -> false; alloc_may_pass({set,_,_,put}) -> false; alloc_may_pass({set,_,_,_}) -> true. I will confer with Bj?rn before pushing anything. // Bj?rn-Egil > > compiling it results in: > > 1> c("/path/to/mapbug", []). > mapbug: function v_msg_m1/1+17: > Internal consistency check failed - please report this bug. > Instruction: return > Error: {stack_frame,undecided}: > > error > > BRs > Tomas > _______________________________________________ > 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 Sat Oct 26 08:21:54 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 26 Oct 2013 10:21:54 +0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <82r4b8ewm7.fsf@assar.nollberga> Message-ID: Is it possible to get list of all keys in map now? -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Oct 26 10:01:34 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sat, 26 Oct 2013 10:01:34 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <82r4b8ewm7.fsf@assar.nollberga> Message-ID: <526B76DE.8020108@ninenines.eu> On 10/26/2013 08:21 AM, Max Lapshin wrote: > Is it possible to get list of all keys in map now? 1> maps:keys(#{a=>b,c=>d}). [a,c] -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From max.lapshin@REDACTED Sat Oct 26 10:13:25 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 26 Oct 2013 12:13:25 +0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526B76DE.8020108@ninenines.eu> References: <526A9E59.7090406@erlang.org> <82r4b8ewm7.fsf@assar.nollberga> <526B76DE.8020108@ninenines.eu> Message-ID: Sorry for my inattention and silly questions =( Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Oct 26 12:00:40 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 26 Oct 2013 12:00:40 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: <577691CA-8381-4663-9BFB-8559D403DC7D@gmail.com> Is someone already working on that or not yet at all? -- Anthony Ramine Le 25 oct. 2013 ? 18:37, Bj?rn-Egil Dahlberg a ?crit : > Variables in Keys > > This feature is actually furthest down on the work prio list. We want to stabilize the current features before moving forward and variable keys is the one most likely to be dropped if we get pressed for time. Meaning, it might not be implemented for R17 but instead implemented for R18. The plan right now is to keep it though. From wallentin.dahlberg@REDACTED Sat Oct 26 15:08:32 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Oct 2013 15:08:32 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <577691CA-8381-4663-9BFB-8559D403DC7D@gmail.com> References: <526A9E59.7090406@erlang.org> <577691CA-8381-4663-9BFB-8559D403DC7D@gmail.com> Message-ID: 2013/10/26 Anthony Ramine > Is someone already working on that or not yet at all? > Heh .. nope, no one is working on it, nor should someone be working on it I think. Not yet at least. For this one, most of the compiler work is pretty straight forward though and the challenge is in the matching compiler in the kernel pass. Making it efficient. Before working on this for Maps, things need to stabilize in the compiler. Since binaries should have the same behavior for bindings, one might look at that first. > > -- > Anthony Ramine > > Le 25 oct. 2013 ? 18:37, Bj?rn-Egil Dahlberg a ?crit : > > > Variables in Keys > > > > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys is > the one most likely to be dropped if we get pressed for time. Meaning, it > might not be implemented for R17 but instead implemented for R18. The plan > right now is to keep it though. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Oct 26 15:11:20 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 26 Oct 2013 15:11:20 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <577691CA-8381-4663-9BFB-8559D403DC7D@gmail.com> Message-ID: Yeah I meant the basic bits needed to implement variable key patterns, i.e. making them work for binaries first. -- Anthony Ramine Le 26 oct. 2013 ? 15:08, Bj?rn-Egil Dahlberg a ?crit : > Heh .. nope, no one is working on it, nor should someone be working on it I think. Not yet at least. > > For this one, most of the compiler work is pretty straight forward though and the challenge is in the matching compiler in the kernel pass. Making it efficient. Before working on this for Maps, things need to stabilize in the compiler. Since binaries should have the same behavior for bindings, one might look at that first. From wallentin.dahlberg@REDACTED Sat Oct 26 15:23:17 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Oct 2013 15:23:17 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <577691CA-8381-4663-9BFB-8559D403DC7D@gmail.com> Message-ID: 2013/10/26 Anthony Ramine > Yeah I meant the basic bits needed to implement variable key patterns, > i.e. making them work for binaries first. > I actually don't know how it looks with that (it's part of another team). I know it's part of the backlog for R17 but the amount of additional work coming in from .. wherever .. leads to changes. I'm not sure if I'm comfortable discussing the prioritizing of work though =) > > -- > Anthony Ramine > > Le 26 oct. 2013 ? 15:08, Bj?rn-Egil Dahlberg > a ?crit : > > > Heh .. nope, no one is working on it, nor should someone be working on > it I think. Not yet at least. > > > > For this one, most of the compiler work is pretty straight forward > though and the challenge is in the matching compiler in the kernel pass. > Making it efficient. Before working on this for Maps, things need to > stabilize in the compiler. Since binaries should have the same behavior for > bindings, one might look at that first. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klas.johansson@REDACTED Sat Oct 26 15:46:49 2013 From: klas.johansson@REDACTED (Klas Johansson) Date: Sat, 26 Oct 2013 15:46:49 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: Hi, Nice! I noticed that syntax_tools needs to be updated with support for maps. Perhaps you already have that on some list? Keep up the good work. :-) Cheers, Klas On Fri, Oct 25, 2013 at 6:37 PM, Bj?rn-Egil Dahlberg wrote: > Hi! > > Here you go, Maps! > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > To get the branch, > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > or find it at > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > I want to state the following so there is no room for uncertainty: > - This branch contains a *development stage* of the *experimental* Maps > feature for Erlang. > > This means: > - Do not use it in production since it is not stable, > - Do not base any git branch on this branch since it will most likely be > rebased, > - and finally, we reserve the right to change any API or interfaces to > Maps currently implemented. > > The implementation is based on EEP 43 - Maps, see > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. > > *What is implemented?* > > The maps module API and erlang guard BIFs as defined in the EEP are > implemented. There are however some sematic mismatches with the EEP. I > think those are where the definition contradict itself. For instance > maps:is_key/1 compares with =:= as stated first in the definition but the > later example uses lists:keymember which compares with ==. > > The syntax and all what that entails is implemented. The compiler will > handle the map syntax and produce loadable beam-code. I believe this is > what people want to test and is what I want people to test. Test the > usability that is. > > I recommend people look at the EEP for information and also the testsuite > located at erts/emulator/test/map_SUITE.erl for information on how to use > Maps since no other documentation is available. > > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > > Where the operator '=>' (assoc operator) is used for extending and > creating new Maps and the operator ':=' is used to update existing > key/values. The ':=' operator is the only operator allowed in patterns. I'm > guessing some confusion will arise from these two types of operators on > where you can and/or should use them. > > Look at the tests and EEP for details and inspiration. > > A major difference from the EEP are variables in keys. Variables in keys > are not allowed at all. This is because we want to reduce the scope for > this first stage. Plenty to do besides that. > > Here are some additional disclaimers to make people sad. > > *What is not implemented?* > > - No variable keys. > - No single value access. > - No map comprehensions. > - No datastructure to handle large Maps. > - No MatchSpecs which uses the Maps syntax will work. > > *Known issues* > > - Dialyzer will not work with maps in the code, this include PLT building > with erts and stdlib. > - HiPE, the native compiler, will not with maps code. > - EDoc will not work with maps. > > I'm sure there are other issues as well, it is a development branch after > all. =) > > I would also like to point out that no optimizations are done either with > respect to the generated code. This means that the instruction set may > change. We know of several optimization we want to do before R17, > especially for the match compiler so keep that in mind. > > We will continue stabilizing the Maps implementation as we move forward > towards R17 and take appropriate action depending on the feedback you give > us. > > I would like to continue with saying a few words about possible changes > that we are thinking about. > > *Variables in Keys* > > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys is > the one most likely to be dropped if we get pressed for time. Meaning, it > might not be implemented for R17 but instead implemented for R18. The plan > right now is to keep it though. > > *The External Format* > > The current external format *needs* ordered keys as input for > binary_to_term/1 and in distribution. > > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I instead > propose that the external format should handle unordered input of key-value > pairs. The trade off is a more complicated decoding which will take longer. > > The distribution format should also be extended to be able cache keys. > This is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all along > but it not mentioned in the EEP. > > *Term order and sorting* > > Finally the term order. This has been a sore point from the get go. > > Maps currently respects the Erlang term order for it's keys. > > The Erlang term order is what I call arithmetic term order. I propose that > we extend Erlang with true term order where integer compares less then > float, i.e. total term order. > > This would allowing newer ordered data structures, like maps, to be more > useful. We don't have to take > special care for the odd cases like keys 1.0 and 1 inhabiting the same > slot in the data structure. gb_trees and such structures could also be > extended to use this as those structures has the same limitations. > > With this type ordering we could have maps with this type of keys, #{ 1 => > "integer", 1.0 => "float" } without causing confusion. > > I've been told that ETS ordered sets tables used to have this behaviour. > Distinguishing between floats and integers. This was supposedly before the > open source era, way back when dinosaurs roamed the planet .. I'm not clear > on the details on why this behaviour was removed. Probably because of > inconsistencies. > > For maps to work with this I only need two things. First, a compare > operation in the runtime that can distinguish between floats and integers, > very easy. Secondly, a BIF that sort a list of terms with this new compare > operation which will be used in the compiler. > > But for completness, the following operators should also be implemented: > > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > > So, true = 1 <:< 1.0. > > I don't know prolog but perhaps these sematics should mimic prolog to > respect Erlangs heritage. I have no strong opinion on this. > > This syntax would mimic the already present =:= and =/= relational > operators hower this syntax is another topic and should be a seperate EEP. > > Happy testing! > > Regards, > Bj?rn-Egil Dahlberg > Erlang/OTP > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.abrahamsson@REDACTED Sat Oct 26 17:40:45 2013 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Sat, 26 Oct 2013 17:40:45 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: (=?iso-8859-1?Q?=22Bj=F6rn-Egil?= Dahlberg"'s message of "Sat, 26 Oct 2013 04:52:18 +0200") References: <526A9E59.7090406@erlang.org> <82r4b8ewm7.fsf@assar.nollberga> Message-ID: <82mwlwdoqq.fsf@assar.nollberga> Bj?rn-Egil Dahlberg writes: > 2013/10/26 Tomas Abrahamsson >> Here you go, Maps! >> >> I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > I also stumbled upon an what appears to be a compiler error. > I believe I found the bug. My attention is a bit split right now so I'm > not completely sure .. watching Vancouver Canucks beat the Blues, and > watching WCS Season 3. > However I think the allocate stack above a fail label which may jump > over a deallocate causes this problem. The following will solve the > problem: Hehe, Nice work, especially considering split attention :) It appears to work well: no more compiler errors, and the code seems to runs fine. I did some tests for map update perforamnce as well. It was 3--4% faster than corresponding record updates, when updating one field at a time for each parse message field. Very nice! One question: will it be possible to use single-field map accesses in guards, for example in if clauses, the same way single-field record accesses can be used? For example: if V1#msg.type == x -> something; V2#{type} == x -> something_else end I suppose that will be the case, but didn't find it explicitly stated in the eep. BRs Tomas From fxmywc@REDACTED Sat Oct 26 16:02:14 2013 From: fxmywc@REDACTED (fxmy wang) Date: Sat, 26 Oct 2013 22:02:14 +0800 Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: <52651984.6000507@gmail.com> References: <52651984.6000507@gmail.com> Message-ID: Could it because that you are using my_supervisor:start_link(), so the start() function and the top supervisor is linked . Then once the start() function executes and quits, your top supervisor also quits. Then brings your whole application down . After you added an infinite receive, you block your start() function from exciting , thus your whole application is ruining fine ? 2013?10?21? ??9:33? "Michael Scofield" ??? > Hi all! I'm new to erlang for a few month. > > Recently I've developed a small pure erlang program, and it runs well in > the shell. Now I want to run it in the background, as a daemon service > process in the os (mine is Ubuntu 12.04 64bit with R16B). So I googled "run > erlang without shell", and google gave me some advice: > > 1. Using escript. -This is what erlang official faq suggested ( > http://www.erlang.org/faq/how_do_i.html). > 2. erl -detached -s Module Function Args > > I tried both. As to #1, my escript goes to > > #!/usr/bin/env escript > main(_) -> > my_supervisor:start_link(arg1, arg2). > > I ran it using "nohup ./my-escript &", and it didn't run my code. =( > > So I went to #2. I was acknowledged that "-s" can only pass 0 or 1 > argument, so I wrapped my supervisor using > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2). > > and ran my code as "erl -detached -s run start". But this was also a dead > end. > > I guessed it's because the run:start/0 just returned and finished the > shell(Is it?), so I added a line to the run:start/0: > > -module(run). > -export([start/0]). > > start() -> > my_supervisor:start_link(arg1, arg2), > *receive after infinity -> stop end.* > > And executed "erl -detached -s run start", and everything goes fine! > my_supervisor started to work without the shell! > > Though the problem "solved", I'm very very confused. > 1. Why the "magic line" solved my problem? > 2. What exactly is the proper or right way to run an erlang application in > the background as the command "nohup ... &" does? > > Thanks in advance! > > Michael > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From co7eb@REDACTED Sat Oct 26 16:43:15 2013 From: co7eb@REDACTED (=?iso-8859-1?Q?Ivan_Carmenates_Garc=EDa?=) Date: Sat, 26 Oct 2013 10:43:15 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> Message-ID: <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> Hi all, About this topic, M0 = #{ key => Value1, "key" => Value2}, % for construction. M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates #{ "key" := V } = M1. % for matching I understand maybe the introduction of more operators like => and := for construct the maps. But it does not make thinks a little more complex and confusing? Records have a similar structure like this: R0 = #person{name = ?Juan?, age = 29} Maybe in the future you would like to implement anonymous records like this: R1 = #{name = ?Juan?, age = 29} That?s why the operator = gets out of the question, but it is more easy to learn the entire language when you don?t have so many different ways of doing things. Maybe something like this: M0 = #{ key := Value1, "key" := Value2}, % for construction. M1 = M1#{ "key" := Value3, <<"key">> := Value4 }, % for updates #{ "key" := V } = M1. % for matching Using the same operator for construction and update and matching, or even so you can use the = operator, and when passing the term to maps does not matter if for some other module and its functions it is an anonymous record and for maps that anonymous record means a map construction. Ie: M0 = #{ key = Value1, "key" = Value2}, % for construction. What could be in a future an anonymous record! M1 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates, #{ "key" = V } = M1. % for matching And all records like constructions will seems close equal. You made distinguish a construction of an update by using of the M1#, but I think that breaks the conviction of the Erlang language of immutable variables, I know it is a way to update the records and it is only syntactically but still that, it is ugly to see it syntactically. When you never can do in a normal code A = A + 1, then you see it in maps updates. I rather better something like this: M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates, When M2 is a new variable that will take the value of the current M1 variable with the modifications. Best regards, Ivan. De: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] En nombre de Klas Johansson Enviado el: s?bado, 26 de octubre de 2013 9:47 Para: Bj?rn-Egil Dahlberg CC: Erlang Asunto: Re: [erlang-questions] Maps branch and disclaimers Hi, Nice! I noticed that syntax_tools needs to be updated with support for maps. Perhaps you already have that on some list? Keep up the good work. :-) Cheers, Klas On Fri, Oct 25, 2013 at 6:37 PM, Bj?rn-Egil Dahlberg wrote: Hi! Here you go, Maps! I've pushed a Maps branch to Erlang/OTPs repository at GitHub. To get the branch, git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation or find it at https://github.com/erlang/otp/tree/egil/maps/eep-implementation I want to state the following so there is no room for uncertainty: - This branch contains a development stage of the experimental Maps feature for Erlang. This means: - Do not use it in production since it is not stable, - Do not base any git branch on this branch since it will most likely be rebased, - and finally, we reserve the right to change any API or interfaces to Maps currently implemented. The implementation is based on EEP 43 - Maps, see http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. What is implemented? The maps module API and erlang guard BIFs as defined in the EEP are implemented. There are however some sematic mismatches with the EEP. I think those are where the definition contradict itself. For instance maps:is_key/1 compares with =:= as stated first in the definition but the later example uses lists:keymember which compares with ==. The syntax and all what that entails is implemented. The compiler will handle the map syntax and produce loadable beam-code. I believe this is what people want to test and is what I want people to test. Test the usability that is. I recommend people look at the EEP for information and also the testsuite located at erts/emulator/test/map_SUITE.erl for information on how to use Maps since no other documentation is available. Roughly, M0 = #{ key => Value1, "key" => Value2}, % for construction. M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates #{ "key" := V } = M1. % for matching Where the operator '=>' (assoc operator) is used for extending and creating new Maps and the operator ':=' is used to update existing key/values. The ':=' operator is the only operator allowed in patterns. I'm guessing some confusion will arise from these two types of operators on where you can and/or should use them. Look at the tests and EEP for details and inspiration. A major difference from the EEP are variables in keys. Variables in keys are not allowed at all. This is because we want to reduce the scope for this first stage. Plenty to do besides that. Here are some additional disclaimers to make people sad. What is not implemented? - No variable keys. - No single value access. - No map comprehensions. - No datastructure to handle large Maps. - No MatchSpecs which uses the Maps syntax will work. Known issues - Dialyzer will not work with maps in the code, this include PLT building with erts and stdlib. - HiPE, the native compiler, will not with maps code. - EDoc will not work with maps. I'm sure there are other issues as well, it is a development branch after all. =) I would also like to point out that no optimizations are done either with respect to the generated code. This means that the instruction set may change. We know of several optimization we want to do before R17, especially for the match compiler so keep that in mind. We will continue stabilizing the Maps implementation as we move forward towards R17 and take appropriate action depending on the feedback you give us. I would like to continue with saying a few words about possible changes that we are thinking about. Variables in Keys This feature is actually furthest down on the work prio list. We want to stabilize the current features before moving forward and variable keys is the one most likely to be dropped if we get pressed for time. Meaning, it might not be implemented for R17 but instead implemented for R18. The plan right now is to keep it though. The External Format The current external format needs ordered keys as input for binary_to_term/1 and in distribution. This is of course an inconvinience when dealing with other language interfaces which has no idea of what the erlang term order is. I instead propose that the external format should handle unordered input of key-value pairs. The trade off is a more complicated decoding which will take longer. The distribution format should also be extended to be able cache keys. This is similar to the atom cache except we cache the entire key array for maps. This has been the intention all along but it not mentioned in the EEP. Term order and sorting Finally the term order. This has been a sore point from the get go. Maps currently respects the Erlang term order for it's keys. The Erlang term order is what I call arithmetic term order. I propose that we extend Erlang with true term order where integer compares less then float, i.e. total term order. This would allowing newer ordered data structures, like maps, to be more useful. We don't have to take special care for the odd cases like keys 1.0 and 1 inhabiting the same slot in the data structure. gb_trees and such structures could also be extended to use this as those structures has the same limitations. With this type ordering we could have maps with this type of keys, #{ 1 => "integer", 1.0 => "float" } without causing confusion. I've been told that ETS ordered sets tables used to have this behaviour. Distinguishing between floats and integers. This was supposedly before the open source era, way back when dinosaurs roamed the planet .. I'm not clear on the details on why this behaviour was removed. Probably because of inconsistencies. For maps to work with this I only need two things. First, a compare operation in the runtime that can distinguish between floats and integers, very easy. Secondly, a BIF that sort a list of terms with this new compare operation which will be used in the compiler. But for completness, the following operators should also be implemented: =:= term exact equal to, already implemented =/= term not equal to, already implemented =:< term less or equal than >:= term greater or equal than <:< term less than >:> term greater than So, true = 1 <:< 1.0. I don't know prolog but perhaps these sematics should mimic prolog to respect Erlangs heritage. I have no strong opinion on this. This syntax would mimic the already present =:= and =/= relational operators hower this syntax is another topic and should be a seperate EEP. Happy testing! Regards, Bj?rn-Egil Dahlberg Erlang/OTP _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Sat Oct 26 19:35:29 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Oct 2013 19:35:29 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> References: <526A9E59.7090406@erlang.org> <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> Message-ID: 2013/10/26 Ivan Carmenates Garc?a > > > You made distinguish a construction of an update by using of the M1#, but > I think that breaks the conviction of the Erlang language of immutable > variables, I know it is a way to update the records and it is only > syntactically but still that, it is ugly to see it syntactically. When you > never can do in a normal code A = A + 1, then you see it in maps updates. I > rather better something like this:**** > > ** ** > > M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates,**** > > ** ** > > When M2 is a new variable that will take the value of the current M1 > variable with the modifications. > As I explained in an earlier answer, It was an unfortunate typo, it should have been, M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates, As for the two operators, it is fairly covered in the EEP on why and how. There are two because it removes the possibility of adding new keys where none should have been added, it is guarded by := , that's why. As for using the = operator, it is also covered in the EEP. // Bj?rn-Egil > **** > > > > **** > > Best regards,**** > > Ivan.**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *De:* erlang-questions-bounces@REDACTED [mailto: > erlang-questions-bounces@REDACTED] *En nombre de *Klas Johansson > *Enviado el:* s?bado, 26 de octubre de 2013 9:47 > *Para:* Bj?rn-Egil Dahlberg > *CC:* Erlang > *Asunto:* Re: [erlang-questions] Maps branch and disclaimers**** > > ** ** > > Hi,**** > > ** ** > > Nice!**** > > ** ** > > I noticed that syntax_tools needs to be updated with support for maps. > Perhaps you already have that on some list?**** > > ** ** > > Keep up the good work. :-)**** > > ** ** > > ** ** > > Cheers,**** > > Klas**** > > ** ** > > ** ** > > On Fri, Oct 25, 2013 at 6:37 PM, Bj?rn-Egil Dahlberg > wrote:**** > > Hi! > > Here you go, Maps! > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > To get the branch, > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > or find it at > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > I want to state the following so there is no room for uncertainty: > - This branch contains a *development stage* of the *experimental* Maps > feature for Erlang. > > This means: > - Do not use it in production since it is not stable, > - Do not base any git branch on this branch since it will most likely be > rebased, > - and finally, we reserve the right to change any API or interfaces to > Maps currently implemented. > > The implementation is based on EEP 43 - Maps, see > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. > > *What is implemented?* > > The maps module API and erlang guard BIFs as defined in the EEP are > implemented. There are however some sematic mismatches with the EEP. I > think those are where the definition contradict itself. For instance > maps:is_key/1 compares with =:= as stated first in the definition but the > later example uses lists:keymember which compares with ==. > > The syntax and all what that entails is implemented. The compiler will > handle the map syntax and produce loadable beam-code. I believe this is > what people want to test and is what I want people to test. Test the > usability that is. > > I recommend people look at the EEP for information and also the testsuite > located at erts/emulator/test/map_SUITE.erl for information on how to use > Maps since no other documentation is available. > > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > > Where the operator '=>' (assoc operator) is used for extending and > creating new Maps and the operator ':=' is used to update existing > key/values. The ':=' operator is the only operator allowed in patterns. I'm > guessing some confusion will arise from these two types of operators on > where you can and/or should use them. > > Look at the tests and EEP for details and inspiration. > > A major difference from the EEP are variables in keys. Variables in keys > are not allowed at all. This is because we want to reduce the scope for > this first stage. Plenty to do besides that. > > Here are some additional disclaimers to make people sad. > > *What is not implemented?* > > - No variable keys. > - No single value access. > - No map comprehensions. > - No datastructure to handle large Maps. > - No MatchSpecs which uses the Maps syntax will work. > > *Known issues* > > - Dialyzer will not work with maps in the code, this include PLT building > with erts and stdlib. > - HiPE, the native compiler, will not with maps code. > - EDoc will not work with maps. > > I'm sure there are other issues as well, it is a development branch after > all. =) > > I would also like to point out that no optimizations are done either with > respect to the generated code. This means that the instruction set may > change. We know of several optimization we want to do before R17, > especially for the match compiler so keep that in mind. > > We will continue stabilizing the Maps implementation as we move forward > towards R17 and take appropriate action depending on the feedback you give > us. > > I would like to continue with saying a few words about possible changes > that we are thinking about. > > *Variables in Keys* > > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys is > the one most likely to be dropped if we get pressed for time. Meaning, it > might not be implemented for R17 but instead implemented for R18. The plan > right now is to keep it though. > > *The External Format* > > The current external format *needs* ordered keys as input for > binary_to_term/1 and in distribution. > > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I instead > propose that the external format should handle unordered input of key-value > pairs. The trade off is a more complicated decoding which will take longer. > > The distribution format should also be extended to be able cache keys. > This is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all along > but it not mentioned in the EEP. > > *Term order and sorting* > > Finally the term order. This has been a sore point from the get go. > > Maps currently respects the Erlang term order for it's keys. > > The Erlang term order is what I call arithmetic term order. I propose that > we extend Erlang with true term order where integer compares less then > float, i.e. total term order. > > This would allowing newer ordered data structures, like maps, to be more > useful. We don't have to take > special care for the odd cases like keys 1.0 and 1 inhabiting the same > slot in the data structure. gb_trees and such structures could also be > extended to use this as those structures has the same limitations. > > With this type ordering we could have maps with this type of keys, #{ 1 => > "integer", 1.0 => "float" } without causing confusion. > > I've been told that ETS ordered sets tables used to have this behaviour. > Distinguishing between floats and integers. This was supposedly before the > open source era, way back when dinosaurs roamed the planet .. I'm not clear > on the details on why this behaviour was removed. Probably because of > inconsistencies. > > For maps to work with this I only need two things. First, a compare > operation in the runtime that can distinguish between floats and integers, > very easy. Secondly, a BIF that sort a list of terms with this new compare > operation which will be used in the compiler. > > But for completness, the following operators should also be implemented: > > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > > So, true = 1 <:< 1.0. > > I don't know prolog but perhaps these sematics should mimic prolog to > respect Erlangs heritage. I have no strong opinion on this. > > This syntax would mimic the already present =:= and =/= relational > operators hower this syntax is another topic and should be a seperate EEP. > > Happy testing! > > Regards, > Bj?rn-Egil Dahlberg > Erlang/OTP**** > > > _______________________________________________ > 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 pierrefenoll@REDACTED Sat Oct 26 22:46:27 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Sat, 26 Oct 2013 21:46:27 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> Message-ID: Hey Bj?rn, Looking at the grammar changes in erl_parse.yrl it seems that this operation is not valid: M2 = fcall()#{ "key" = Value3, <<"key">> = Value4 }, % for updates, "M1" has been changed to "fcall()", representing a (any) function call. What that means is that one can't query maps directly from a function's output. It just would not compile. This issue can be fixed by just s/expr_max/expr_700/ on this line: https://github.com/erlang/otp/blob/egil/maps/eep-implementation/lib/stdlib/src/erl_parse.yrl#L341 (Grammar rule expr_700 holds the function_call rule). Maybe adding explicitly the function_call rule to the map_expr rule is better though: map_expr -> ? map_expr -> function_call '#' map_tuple : {map, ?line('$2'),'$1','$3'}. Cheers, -- Pierre Fenoll On 26 October 2013 18:35, Bj?rn-Egil Dahlberg wrote: > > > > 2013/10/26 Ivan Carmenates Garc?a > >> >> >> You made distinguish a construction of an update by using of the M1#, but >> I think that breaks the conviction of the Erlang language of immutable >> variables, I know it is a way to update the records and it is only >> syntactically but still that, it is ugly to see it syntactically. When you >> never can do in a normal code A = A + 1, then you see it in maps updates. I >> rather better something like this:**** >> >> ** ** >> >> M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates,**** >> >> ** ** >> >> When M2 is a new variable that will take the value of the current M1 >> variable with the modifications. >> > > As I explained in an earlier answer, It was an unfortunate typo, it should > have been, > > M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates, > > > As for the two operators, it is fairly covered in the EEP on why and how. > There are two because it removes the possibility of adding new keys where > none should have been added, it is guarded by := , that's why. > > As for using the = operator, it is also covered in the EEP. > > // Bj?rn-Egil > > > > >> **** >> >> >> >> **** >> >> Best regards,**** >> >> Ivan.**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *De:* erlang-questions-bounces@REDACTED [mailto: >> erlang-questions-bounces@REDACTED] *En nombre de *Klas Johansson >> *Enviado el:* s?bado, 26 de octubre de 2013 9:47 >> *Para:* Bj?rn-Egil Dahlberg >> *CC:* Erlang >> *Asunto:* Re: [erlang-questions] Maps branch and disclaimers**** >> >> ** ** >> >> Hi,**** >> >> ** ** >> >> Nice!**** >> >> ** ** >> >> I noticed that syntax_tools needs to be updated with support for maps. >> Perhaps you already have that on some list?**** >> >> ** ** >> >> Keep up the good work. :-)**** >> >> ** ** >> >> ** ** >> >> Cheers,**** >> >> Klas**** >> >> ** ** >> >> ** ** >> >> On Fri, Oct 25, 2013 at 6:37 PM, Bj?rn-Egil Dahlberg >> wrote:**** >> >> Hi! >> >> Here you go, Maps! >> >> I've pushed a Maps branch to Erlang/OTPs repository at GitHub. >> >> To get the branch, >> >> git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation >> >> or find it at >> https://github.com/erlang/otp/tree/egil/maps/eep-implementation >> >> I want to state the following so there is no room for uncertainty: >> - This branch contains a *development stage* of the *experimental* Maps >> feature for Erlang. >> >> This means: >> - Do not use it in production since it is not stable, >> - Do not base any git branch on this branch since it will most likely be >> rebased, >> - and finally, we reserve the right to change any API or interfaces to >> Maps currently implemented. >> >> The implementation is based on EEP 43 - Maps, see >> http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. >> >> *What is implemented?* >> >> The maps module API and erlang guard BIFs as defined in the EEP are >> implemented. There are however some sematic mismatches with the EEP. I >> think those are where the definition contradict itself. For instance >> maps:is_key/1 compares with =:= as stated first in the definition but the >> later example uses lists:keymember which compares with ==. >> >> The syntax and all what that entails is implemented. The compiler will >> handle the map syntax and produce loadable beam-code. I believe this is >> what people want to test and is what I want people to test. Test the >> usability that is. >> >> I recommend people look at the EEP for information and also the testsuite >> located at erts/emulator/test/map_SUITE.erl for information on how to >> use Maps since no other documentation is available. >> >> Roughly, >> M0 = #{ key => Value1, "key" => Value2}, % for construction. >> M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates >> #{ "key" := V } = M1. % for matching >> >> Where the operator '=>' (assoc operator) is used for extending and >> creating new Maps and the operator ':=' is used to update existing >> key/values. The ':=' operator is the only operator allowed in patterns. I'm >> guessing some confusion will arise from these two types of operators on >> where you can and/or should use them. >> >> Look at the tests and EEP for details and inspiration. >> >> A major difference from the EEP are variables in keys. Variables in keys >> are not allowed at all. This is because we want to reduce the scope for >> this first stage. Plenty to do besides that. >> >> Here are some additional disclaimers to make people sad. >> >> *What is not implemented?* >> >> - No variable keys. >> - No single value access. >> - No map comprehensions. >> - No datastructure to handle large Maps. >> - No MatchSpecs which uses the Maps syntax will work. >> >> *Known issues* >> >> - Dialyzer will not work with maps in the code, this include PLT building >> with erts and stdlib. >> - HiPE, the native compiler, will not with maps code. >> - EDoc will not work with maps. >> >> I'm sure there are other issues as well, it is a development branch after >> all. =) >> >> I would also like to point out that no optimizations are done either with >> respect to the generated code. This means that the instruction set may >> change. We know of several optimization we want to do before R17, >> especially for the match compiler so keep that in mind. >> >> We will continue stabilizing the Maps implementation as we move forward >> towards R17 and take appropriate action depending on the feedback you give >> us. >> >> I would like to continue with saying a few words about possible changes >> that we are thinking about. >> >> *Variables in Keys* >> >> This feature is actually furthest down on the work prio list. We want to >> stabilize the current features before moving forward and variable keys is >> the one most likely to be dropped if we get pressed for time. Meaning, it >> might not be implemented for R17 but instead implemented for R18. The plan >> right now is to keep it though. >> >> *The External Format* >> >> The current external format *needs* ordered keys as input for >> binary_to_term/1 and in distribution. >> >> This is of course an inconvinience when dealing with other language >> interfaces which has no idea of what the erlang term order is. I instead >> propose that the external format should handle unordered input of key-value >> pairs. The trade off is a more complicated decoding which will take longer. >> >> The distribution format should also be extended to be able cache keys. >> This is similar to the atom cache except we >> cache the entire key array for maps. This has been the intention all >> along but it not mentioned in the EEP. >> >> *Term order and sorting* >> >> Finally the term order. This has been a sore point from the get go. >> >> Maps currently respects the Erlang term order for it's keys. >> >> The Erlang term order is what I call arithmetic term order. I propose >> that we extend Erlang with true term order where integer compares less then >> float, i.e. total term order. >> >> This would allowing newer ordered data structures, like maps, to be more >> useful. We don't have to take >> special care for the odd cases like keys 1.0 and 1 inhabiting the same >> slot in the data structure. gb_trees and such structures could also be >> extended to use this as those structures has the same limitations. >> >> With this type ordering we could have maps with this type of keys, #{ 1 >> => "integer", 1.0 => "float" } without causing confusion. >> >> I've been told that ETS ordered sets tables used to have this behaviour. >> Distinguishing between floats and integers. This was supposedly before the >> open source era, way back when dinosaurs roamed the planet .. I'm not clear >> on the details on why this behaviour was removed. Probably because of >> inconsistencies. >> >> For maps to work with this I only need two things. First, a compare >> operation in the runtime that can distinguish between floats and integers, >> very easy. Secondly, a BIF that sort a list of terms with this new compare >> operation which will be used in the compiler. >> >> But for completness, the following operators should also be implemented: >> >> =:= term exact equal to, already implemented >> =/= term not equal to, already implemented >> =:< term less or equal than >> >:= term greater or equal than >> <:< term less than >> >:> term greater than >> >> So, true = 1 <:< 1.0. >> >> I don't know prolog but perhaps these sematics should mimic prolog to >> respect Erlangs heritage. I have no strong opinion on this. >> >> This syntax would mimic the already present =:= and =/= relational >> operators hower this syntax is another topic and should be a seperate EEP. >> >> Happy testing! >> >> Regards, >> Bj?rn-Egil Dahlberg >> Erlang/OTP**** >> >> >> _______________________________________________ >> 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 wallentin.dahlberg@REDACTED Sat Oct 26 23:33:20 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 26 Oct 2013 23:33:20 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> Message-ID: 2013/10/26 Bj?rn-Egil Dahlberg > > > > 2013/10/26 Ivan Carmenates Garc?a > >> >> >> You made distinguish a construction of an update by using of the M1#, but >> I think that breaks the conviction of the Erlang language of immutable >> variables, I know it is a way to update the records and it is only >> syntactically but still that, it is ugly to see it syntactically. When you >> never can do in a normal code A = A + 1, then you see it in maps updates. I >> rather better something like this:**** >> >> ** ** >> >> M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates,**** >> >> ** ** >> >> When M2 is a new variable that will take the value of the current M1 >> variable with the modifications. >> > > As I explained in an earlier answer, It was an unfortunate typo, it should > have been, > > M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates, > Did I just .. ok .. blaming fever =) M2 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates, > > > > As for the two operators, it is fairly covered in the EEP on why and how. > There are two because it removes the possibility of adding new keys where > none should have been added, it is guarded by := , that's why. > > As for using the = operator, it is also covered in the EEP. > > // Bj?rn-Egil > > > > >> **** >> >> >> >> **** >> >> Best regards,**** >> >> Ivan.**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *De:* erlang-questions-bounces@REDACTED [mailto: >> erlang-questions-bounces@REDACTED] *En nombre de *Klas Johansson >> *Enviado el:* s?bado, 26 de octubre de 2013 9:47 >> *Para:* Bj?rn-Egil Dahlberg >> *CC:* Erlang >> *Asunto:* Re: [erlang-questions] Maps branch and disclaimers**** >> >> ** ** >> >> Hi,**** >> >> ** ** >> >> Nice!**** >> >> ** ** >> >> I noticed that syntax_tools needs to be updated with support for maps. >> Perhaps you already have that on some list?**** >> >> ** ** >> >> Keep up the good work. :-)**** >> >> ** ** >> >> ** ** >> >> Cheers,**** >> >> Klas**** >> >> ** ** >> >> ** ** >> >> On Fri, Oct 25, 2013 at 6:37 PM, Bj?rn-Egil Dahlberg >> wrote:**** >> >> Hi! >> >> Here you go, Maps! >> >> I've pushed a Maps branch to Erlang/OTPs repository at GitHub. >> >> To get the branch, >> >> git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation >> >> or find it at >> https://github.com/erlang/otp/tree/egil/maps/eep-implementation >> >> I want to state the following so there is no room for uncertainty: >> - This branch contains a *development stage* of the *experimental* Maps >> feature for Erlang. >> >> This means: >> - Do not use it in production since it is not stable, >> - Do not base any git branch on this branch since it will most likely be >> rebased, >> - and finally, we reserve the right to change any API or interfaces to >> Maps currently implemented. >> >> The implementation is based on EEP 43 - Maps, see >> http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. >> >> *What is implemented?* >> >> The maps module API and erlang guard BIFs as defined in the EEP are >> implemented. There are however some sematic mismatches with the EEP. I >> think those are where the definition contradict itself. For instance >> maps:is_key/1 compares with =:= as stated first in the definition but the >> later example uses lists:keymember which compares with ==. >> >> The syntax and all what that entails is implemented. The compiler will >> handle the map syntax and produce loadable beam-code. I believe this is >> what people want to test and is what I want people to test. Test the >> usability that is. >> >> I recommend people look at the EEP for information and also the testsuite >> located at erts/emulator/test/map_SUITE.erl for information on how to >> use Maps since no other documentation is available. >> >> Roughly, >> M0 = #{ key => Value1, "key" => Value2}, % for construction. >> M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates >> #{ "key" := V } = M1. % for matching >> >> Where the operator '=>' (assoc operator) is used for extending and >> creating new Maps and the operator ':=' is used to update existing >> key/values. The ':=' operator is the only operator allowed in patterns. I'm >> guessing some confusion will arise from these two types of operators on >> where you can and/or should use them. >> >> Look at the tests and EEP for details and inspiration. >> >> A major difference from the EEP are variables in keys. Variables in keys >> are not allowed at all. This is because we want to reduce the scope for >> this first stage. Plenty to do besides that. >> >> Here are some additional disclaimers to make people sad. >> >> *What is not implemented?* >> >> - No variable keys. >> - No single value access. >> - No map comprehensions. >> - No datastructure to handle large Maps. >> - No MatchSpecs which uses the Maps syntax will work. >> >> *Known issues* >> >> - Dialyzer will not work with maps in the code, this include PLT building >> with erts and stdlib. >> - HiPE, the native compiler, will not with maps code. >> - EDoc will not work with maps. >> >> I'm sure there are other issues as well, it is a development branch after >> all. =) >> >> I would also like to point out that no optimizations are done either with >> respect to the generated code. This means that the instruction set may >> change. We know of several optimization we want to do before R17, >> especially for the match compiler so keep that in mind. >> >> We will continue stabilizing the Maps implementation as we move forward >> towards R17 and take appropriate action depending on the feedback you give >> us. >> >> I would like to continue with saying a few words about possible changes >> that we are thinking about. >> >> *Variables in Keys* >> >> This feature is actually furthest down on the work prio list. We want to >> stabilize the current features before moving forward and variable keys is >> the one most likely to be dropped if we get pressed for time. Meaning, it >> might not be implemented for R17 but instead implemented for R18. The plan >> right now is to keep it though. >> >> *The External Format* >> >> The current external format *needs* ordered keys as input for >> binary_to_term/1 and in distribution. >> >> This is of course an inconvinience when dealing with other language >> interfaces which has no idea of what the erlang term order is. I instead >> propose that the external format should handle unordered input of key-value >> pairs. The trade off is a more complicated decoding which will take longer. >> >> The distribution format should also be extended to be able cache keys. >> This is similar to the atom cache except we >> cache the entire key array for maps. This has been the intention all >> along but it not mentioned in the EEP. >> >> *Term order and sorting* >> >> Finally the term order. This has been a sore point from the get go. >> >> Maps currently respects the Erlang term order for it's keys. >> >> The Erlang term order is what I call arithmetic term order. I propose >> that we extend Erlang with true term order where integer compares less then >> float, i.e. total term order. >> >> This would allowing newer ordered data structures, like maps, to be more >> useful. We don't have to take >> special care for the odd cases like keys 1.0 and 1 inhabiting the same >> slot in the data structure. gb_trees and such structures could also be >> extended to use this as those structures has the same limitations. >> >> With this type ordering we could have maps with this type of keys, #{ 1 >> => "integer", 1.0 => "float" } without causing confusion. >> >> I've been told that ETS ordered sets tables used to have this behaviour. >> Distinguishing between floats and integers. This was supposedly before the >> open source era, way back when dinosaurs roamed the planet .. I'm not clear >> on the details on why this behaviour was removed. Probably because of >> inconsistencies. >> >> For maps to work with this I only need two things. First, a compare >> operation in the runtime that can distinguish between floats and integers, >> very easy. Secondly, a BIF that sort a list of terms with this new compare >> operation which will be used in the compiler. >> >> But for completness, the following operators should also be implemented: >> >> =:= term exact equal to, already implemented >> =/= term not equal to, already implemented >> =:< term less or equal than >> >:= term greater or equal than >> <:< term less than >> >:> term greater than >> >> So, true = 1 <:< 1.0. >> >> I don't know prolog but perhaps these sematics should mimic prolog to >> respect Erlangs heritage. I have no strong opinion on this. >> >> This syntax would mimic the already present =:= and =/= relational >> operators hower this syntax is another topic and should be a seperate EEP. >> >> Happy testing! >> >> Regards, >> Bj?rn-Egil Dahlberg >> Erlang/OTP**** >> >> >> _______________________________________________ >> 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 wallentin.dahlberg@REDACTED Sun Oct 27 00:17:55 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sun, 27 Oct 2013 00:17:55 +0200 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> Message-ID: 2013/10/26 Pierre Fenoll > Hey Bj?rn, > > Looking at the grammar changes in erl_parse.yrl it seems that this > operation is not valid: > > M2 = fcall()#{ "key" => Value3, <<"key">> := Value4 }, % for updates, > > "M1" has been changed to "fcall()", representing a (any) function call. > What that means is that one can't query maps directly from a function's > output. It just would not compile. > > This issue can be fixed by just s/expr_max/expr_700/ on this line: > https://github.com/erlang/otp/blob/egil/maps/eep-implementation/lib/stdlib/src/erl_parse.yrl#L341 > (Grammar rule expr_700 holds the function_call rule). > Maybe adding explicitly the function_call rule to the map_expr rule is > better though: > > map_expr -> ? > map_expr -> function_call '#' map_tuple : {map, ?line('$2'),'$1','$3'}. > I don't see why not. I think it stated in the EEP that any expression can be placed in front of the Map. I'm not sure how much I like that but I think it is very reasonable. Right now there is a bug i v3_core which crashes this construct. It can be seen by (fcall())#{ "key" => Value3, <<"key">> := Value4 } Apparently it only handle variables .. =) I will look into this during the week. // Bj?rn-Egil > > > Cheers, > -- > Pierre Fenoll > > > > On 26 October 2013 18:35, Bj?rn-Egil Dahlberg < > wallentin.dahlberg@REDACTED> wrote: > >> >> >> >> 2013/10/26 Ivan Carmenates Garc?a >> >>> >>> >>> You made distinguish a construction of an update by using of the M1#, >>> but I think that breaks the conviction of the Erlang language of immutable >>> variables, I know it is a way to update the records and it is only >>> syntactically but still that, it is ugly to see it syntactically. When you >>> never can do in a normal code A = A + 1, then you see it in maps updates. I >>> rather better something like this:**** >>> >>> ** ** >>> >>> M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates,**** >>> >>> ** ** >>> >>> When M2 is a new variable that will take the value of the current M1 >>> variable with the modifications. >>> >> >> As I explained in an earlier answer, It was an unfortunate typo, it >> should have been, >> >> M2 = M1#{ "key" = Value3, <<"key">> = Value4 }, % for updates, >> >> >> As for the two operators, it is fairly covered in the EEP on why and how. >> There are two because it removes the possibility of adding new keys where >> none should have been added, it is guarded by := , that's why. >> >> As for using the = operator, it is also covered in the EEP. >> >> // Bj?rn-Egil >> >> >> >> >>> **** >>> >>> >>> >>> **** >>> >>> Best regards,**** >>> >>> Ivan.**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> *De:* erlang-questions-bounces@REDACTED [mailto: >>> erlang-questions-bounces@REDACTED] *En nombre de *Klas Johansson >>> *Enviado el:* s?bado, 26 de octubre de 2013 9:47 >>> *Para:* Bj?rn-Egil Dahlberg >>> *CC:* Erlang >>> *Asunto:* Re: [erlang-questions] Maps branch and disclaimers**** >>> >>> ** ** >>> >>> Hi,**** >>> >>> ** ** >>> >>> Nice!**** >>> >>> ** ** >>> >>> I noticed that syntax_tools needs to be updated with support for maps. >>> Perhaps you already have that on some list?**** >>> >>> ** ** >>> >>> Keep up the good work. :-)**** >>> >>> ** ** >>> >>> ** ** >>> >>> Cheers,**** >>> >>> Klas**** >>> >>> ** ** >>> >>> ** ** >>> >>> On Fri, Oct 25, 2013 at 6:37 PM, Bj?rn-Egil Dahlberg >>> wrote:**** >>> >>> Hi! >>> >>> Here you go, Maps! >>> >>> I've pushed a Maps branch to Erlang/OTPs repository at GitHub. >>> >>> To get the branch, >>> >>> git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation >>> >>> or find it at >>> https://github.com/erlang/otp/tree/egil/maps/eep-implementation >>> >>> I want to state the following so there is no room for uncertainty: >>> - This branch contains a *development stage* of the *experimental* Maps >>> feature for Erlang. >>> >>> This means: >>> - Do not use it in production since it is not stable, >>> - Do not base any git branch on this branch since it will most likely >>> be rebased, >>> - and finally, we reserve the right to change any API or interfaces to >>> Maps currently implemented. >>> >>> The implementation is based on EEP 43 - Maps, see >>> http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. >>> >>> *What is implemented?* >>> >>> The maps module API and erlang guard BIFs as defined in the EEP are >>> implemented. There are however some sematic mismatches with the EEP. I >>> think those are where the definition contradict itself. For instance >>> maps:is_key/1 compares with =:= as stated first in the definition but the >>> later example uses lists:keymember which compares with ==. >>> >>> The syntax and all what that entails is implemented. The compiler will >>> handle the map syntax and produce loadable beam-code. I believe this is >>> what people want to test and is what I want people to test. Test the >>> usability that is. >>> >>> I recommend people look at the EEP for information and also the >>> testsuite located at erts/emulator/test/map_SUITE.erl for information >>> on how to use Maps since no other documentation is available. >>> >>> Roughly, >>> M0 = #{ key => Value1, "key" => Value2}, % for construction. >>> M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates >>> #{ "key" := V } = M1. % for matching >>> >>> Where the operator '=>' (assoc operator) is used for extending and >>> creating new Maps and the operator ':=' is used to update existing >>> key/values. The ':=' operator is the only operator allowed in patterns. I'm >>> guessing some confusion will arise from these two types of operators on >>> where you can and/or should use them. >>> >>> Look at the tests and EEP for details and inspiration. >>> >>> A major difference from the EEP are variables in keys. Variables in keys >>> are not allowed at all. This is because we want to reduce the scope for >>> this first stage. Plenty to do besides that. >>> >>> Here are some additional disclaimers to make people sad. >>> >>> *What is not implemented?* >>> >>> - No variable keys. >>> - No single value access. >>> - No map comprehensions. >>> - No datastructure to handle large Maps. >>> - No MatchSpecs which uses the Maps syntax will work. >>> >>> *Known issues* >>> >>> - Dialyzer will not work with maps in the code, this include PLT >>> building with erts and stdlib. >>> - HiPE, the native compiler, will not with maps code. >>> - EDoc will not work with maps. >>> >>> I'm sure there are other issues as well, it is a development branch >>> after all. =) >>> >>> I would also like to point out that no optimizations are done either >>> with respect to the generated code. This means that the instruction set may >>> change. We know of several optimization we want to do before R17, >>> especially for the match compiler so keep that in mind. >>> >>> We will continue stabilizing the Maps implementation as we move forward >>> towards R17 and take appropriate action depending on the feedback you give >>> us. >>> >>> I would like to continue with saying a few words about possible changes >>> that we are thinking about. >>> >>> *Variables in Keys* >>> >>> This feature is actually furthest down on the work prio list. We want to >>> stabilize the current features before moving forward and variable keys is >>> the one most likely to be dropped if we get pressed for time. Meaning, it >>> might not be implemented for R17 but instead implemented for R18. The plan >>> right now is to keep it though. >>> >>> *The External Format* >>> >>> The current external format *needs* ordered keys as input for >>> binary_to_term/1 and in distribution. >>> >>> This is of course an inconvinience when dealing with other language >>> interfaces which has no idea of what the erlang term order is. I instead >>> propose that the external format should handle unordered input of key-value >>> pairs. The trade off is a more complicated decoding which will take longer. >>> >>> The distribution format should also be extended to be able cache keys. >>> This is similar to the atom cache except we >>> cache the entire key array for maps. This has been the intention all >>> along but it not mentioned in the EEP. >>> >>> *Term order and sorting* >>> >>> Finally the term order. This has been a sore point from the get go. >>> >>> Maps currently respects the Erlang term order for it's keys. >>> >>> The Erlang term order is what I call arithmetic term order. I propose >>> that we extend Erlang with true term order where integer compares less then >>> float, i.e. total term order. >>> >>> This would allowing newer ordered data structures, like maps, to be more >>> useful. We don't have to take >>> special care for the odd cases like keys 1.0 and 1 inhabiting the same >>> slot in the data structure. gb_trees and such structures could also be >>> extended to use this as those structures has the same limitations. >>> >>> With this type ordering we could have maps with this type of keys, #{ 1 >>> => "integer", 1.0 => "float" } without causing confusion. >>> >>> I've been told that ETS ordered sets tables used to have this behaviour. >>> Distinguishing between floats and integers. This was supposedly before the >>> open source era, way back when dinosaurs roamed the planet .. I'm not clear >>> on the details on why this behaviour was removed. Probably because of >>> inconsistencies. >>> >>> For maps to work with this I only need two things. First, a compare >>> operation in the runtime that can distinguish between floats and integers, >>> very easy. Secondly, a BIF that sort a list of terms with this new compare >>> operation which will be used in the compiler. >>> >>> But for completness, the following operators should also be implemented: >>> >>> =:= term exact equal to, already implemented >>> =/= term not equal to, already implemented >>> =:< term less or equal than >>> >:= term greater or equal than >>> <:< term less than >>> >:> term greater than >>> >>> So, true = 1 <:< 1.0. >>> >>> I don't know prolog but perhaps these sematics should mimic prolog to >>> respect Erlangs heritage. I have no strong opinion on this. >>> >>> This syntax would mimic the already present =:= and =/= relational >>> operators hower this syntax is another topic and should be a seperate EEP. >>> >>> Happy testing! >>> >>> Regards, >>> Bj?rn-Egil Dahlberg >>> Erlang/OTP**** >>> >>> >>> _______________________________________________ >>> 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 tristan.sloughter@REDACTED Sun Oct 27 01:55:43 2013 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sat, 26 Oct 2013 16:55:43 -0700 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> Message-ID: <1382831743.2822.39046341.5B53957E@webmail.messagingengine.com> This is great! And fun. Waiting so long to play with these I had to make a branch of jsx using maps for objects today: [1]https://github.com/tsloughter/jsx/tree/maps -- Tristan Sloughter tristan.sloughter@REDACTED On Fri, Oct 25, 2013, at 07:22 PM, Daniel Goertzen wrote: Works like a charm! Yamler (Erlang yaml file loader) now constructs yaml mappings as erlang maps. I updated the README examples to show these maps in action: [2]https://github.com/goertzenator/yamler/tree/mapping_as_map Thanks for maps! Dan. On Fri, Oct 25, 2013 at 11:37 AM, Bj?rn-Egil Dahlberg <[3]egil@REDACTED> wrote: Hi! Here you go, Maps! I've pushed a Maps branch to Erlang/OTPs repository at GitHub. To get the branch, git fetch [4]git@REDACTED:erlang/otp.git egil/maps/eep-implementation or find it at [5]https://github.com/erlang/otp/tree/egil/maps/eep-implementation I want to state the following so there is no room for uncertainty: - This branch contains a development stage of the experimental Maps feature for Erlang. This means: - Do not use it in production since it is not stable, - Do not base any git branch on this branch since it will most likely be rebased, - and finally, we reserve the right to change any API or interfaces to Maps currently implemented. The implementation is based on EEP 43 - Maps, see [6]http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. What is implemented? The maps module API and erlang guard BIFs as defined in the EEP are implemented. There are however some sematic mismatches with the EEP. I think those are where the definition contradict itself. For instance maps:is_key/1 compares with =:= as stated first in the definition but the later example uses lists:keymember which compares with ==. The syntax and all what that entails is implemented. The compiler will handle the map syntax and produce loadable beam-code. I believe this is what people want to test and is what I want people to test. Test the usability that is. I recommend people look at the EEP for information and also the testsuite located at erts/emulator/test/map_SUITE.erl for information on how to use Maps since no other documentation is available. Roughly, M0 = #{ key => Value1, "key" => Value2}, % for construction. M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates #{ "key" := V } = M1. % for matching Where the operator '=>' (assoc operator) is used for extending and creating new Maps and the operator ':=' is used to update existing key/values. The ':=' operator is the only operator allowed in patterns. I'm guessing some confusion will arise from these two types of operators on where you can and/or should use them. Look at the tests and EEP for details and inspiration. A major difference from the EEP are variables in keys. Variables in keys are not allowed at all. This is because we want to reduce the scope for this first stage. Plenty to do besides that. Here are some additional disclaimers to make people sad. What is not implemented? - No variable keys. - No single value access. - No map comprehensions. - No datastructure to handle large Maps. - No MatchSpecs which uses the Maps syntax will work. Known issues - Dialyzer will not work with maps in the code, this include PLT building with erts and stdlib. - HiPE, the native compiler, will not with maps code. - EDoc will not work with maps. I'm sure there are other issues as well, it is a development branch after all. =) I would also like to point out that no optimizations are done either with respect to the generated code. This means that the instruction set may change. We know of several optimization we want to do before R17, especially for the match compiler so keep that in mind. We will continue stabilizing the Maps implementation as we move forward towards R17 and take appropriate action depending on the feedback you give us. I would like to continue with saying a few words about possible changes that we are thinking about. Variables in Keys This feature is actually furthest down on the work prio list. We want to stabilize the current features before moving forward and variable keys is the one most likely to be dropped if we get pressed for time. Meaning, it might not be implemented for R17 but instead implemented for R18. The plan right now is to keep it though. The External Format The current external format needs ordered keys as input for binary_to_term/1 and in distribution. This is of course an inconvinience when dealing with other language interfaces which has no idea of what the erlang term order is. I instead propose that the external format should handle unordered input of key-value pairs. The trade off is a more complicated decoding which will take longer. The distribution format should also be extended to be able cache keys. This is similar to the atom cache except we cache the entire key array for maps. This has been the intention all along but it not mentioned in the EEP. Term order and sorting Finally the term order. This has been a sore point from the get go. Maps currently respects the Erlang term order for it's keys. The Erlang term order is what I call arithmetic term order. I propose that we extend Erlang with true term order where integer compares less then float, i.e. total term order. This would allowing newer ordered data structures, like maps, to be more useful. We don't have to take special care for the odd cases like keys 1.0 and 1 inhabiting the same slot in the data structure. gb_trees and such structures could also be extended to use this as those structures has the same limitations. With this type ordering we could have maps with this type of keys, #{ 1 => "integer", 1.0 => "float" } without causing confusion. I've been told that ETS ordered sets tables used to have this behaviour. Distinguishing between floats and integers. This was supposedly before the open source era, way back when dinosaurs roamed the planet .. I'm not clear on the details on why this behaviour was removed. Probably because of inconsistencies. For maps to work with this I only need two things. First, a compare operation in the runtime that can distinguish between floats and integers, very easy. Secondly, a BIF that sort a list of terms with this new compare operation which will be used in the compiler. But for completness, the following operators should also be implemented: =:= term exact equal to, already implemented =/= term not equal to, already implemented =:< term less or equal than >:= term greater or equal than <:< term less than >:> term greater than So, true = 1 <:< 1.0. I don't know prolog but perhaps these sematics should mimic prolog to respect Erlangs heritage. I have no strong opinion on this. This syntax would mimic the already present =:= and =/= relational operators hower this syntax is another topic and should be a seperate EEP. Happy testing! Regards, Bj?rn-Egil Dahlberg Erlang/OTP _______________________________________________ erlang-questions mailing list [7]erlang-questions@REDACTED [8]http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [9]erlang-questions@REDACTED [10]http://erlang.org/mailman/listinfo/erlang-questions References 1. https://github.com/tsloughter/jsx/tree/maps 2. https://github.com/goertzenator/yamler/tree/mapping_as_map 3. mailto:egil@REDACTED 4. mailto:git@REDACTED:erlang/otp.git 5. https://github.com/erlang/otp/tree/egil/maps/eep-implementation 6. http://github.com/erlang/eep/blob/master/eeps/eep-0043.md 7. mailto:erlang-questions@REDACTED 8. http://erlang.org/mailman/listinfo/erlang-questions 9. mailto:erlang-questions@REDACTED 10. http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Sun Oct 27 10:45:35 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 27 Oct 2013 09:45:35 +0000 Subject: [erlang-questions] more random uniform Message-ID: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com> Greetings, When doing random:uniform/1 for small values, ie 3, the result is 1 the first time. Changing the seed does not help. What am I missing? Bengt Sent from Moxier Mail (http://www.moxier.com) From tony@REDACTED Sun Oct 27 11:13:25 2013 From: tony@REDACTED (Tony Rogvall) Date: Sun, 27 Oct 2013 11:13:25 +0100 Subject: [erlang-questions] more random uniform In-Reply-To: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com> References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com> Message-ID: I can not replicate this (on R16B01). > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 1 > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 2 ... ? /Tony On 27 okt 2013, at 10:45, Bengt Kleberg wrote: > Greetings, > > When doing random:uniform/1 for small values, ie 3, the result is 1 the first time. Changing the seed does not help. > What am I missing? > > > Bengt > > Sent from Moxier Mail > (http://www.moxier.com) > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Sun Oct 27 11:33:30 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 27 Oct 2013 10:33:30 +0000 Subject: [erlang-questions] more random uniform In-Reply-To: References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com>, Message-ID: <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> Thank you. I have 15B. Is the erase/1 necessary? I am using new processes each time. Bengt Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Tony Rogvall Till: Bengt Kleberg Kopia: "erlang-questions@REDACTED" Skickat: 27-10-2013 11:13 fm ?mne: Re: [erlang-questions] more random uniform I can not replicate this (on R16B01). > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 1 > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 2 ... ? /Tony On 27 okt 2013, at 10:45, Bengt Kleberg > wrote: Greetings, When doing random:uniform/1 for small values, ie 3, the result is 1 the first time. Changing the seed does not help. What am I missing? Bengt Sent from Moxier Mail (http://www.moxier.com) _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Sun Oct 27 11:48:28 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 27 Oct 2013 10:48:28 +0000 Subject: [erlang-questions] more random uniform In-Reply-To: <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com>, , <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> Message-ID: 7> [erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Bengt Kleberg Till: null Kopia: "erlang-questions@REDACTED" Skickat: 27-10-2013 11:33 fm ?mne: Re: [erlang-questions] more random uniform Thank you. I have 15B. Is the erase/1 necessary? I am using new processes each time. Bengt Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Tony Rogvall Till: Bengt Kleberg Kopia: "erlang-questions@REDACTED" Skickat: 27-10-2013 11:13 fm ?mne: Re: [erlang-questions] more random uniform I can not replicate this (on R16B01). > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 1 > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 2 ... ? /Tony On 27 okt 2013, at 10:45, Bengt Kleberg > wrote: Greetings, When doing random:uniform/1 for small values, ie 3, the result is 1 the first time. Changing the seed does not help. What am I missing? Bengt Sent from Moxier Mail (http://www.moxier.com) _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From gleber.p@REDACTED Sun Oct 27 11:58:58 2013 From: gleber.p@REDACTED (Gleb Peregud) Date: Sun, 27 Oct 2013 11:58:58 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <1382831743.2822.39046341.5B53957E@webmail.messagingengine.com> References: <526A9E59.7090406@erlang.org> <1382831743.2822.39046341.5B53957E@webmail.messagingengine.com> Message-ID: Great work, OTP team! I was wondering about one thing. I find abstract modules (a leftover of parametrized modules) a very neat feature in some cases and I was wondering if anyone else would like to be able to something like this with maps: M0 = #{ key => Value1, "key" => Value2}, % for construction. M1 = M0:put("key", Value3), % mapped to maps:put("key", Value3, M0) M2 = M1:put(<<"key">>, Value4) Do you think this is a desirable feature? It can be useful for creating some kind of abstraction layer over multiple implementations of the same interface without having to use macros nor implementing a proxy modules to handle this. Thoughts? Cheers, Gleb On Sun, Oct 27, 2013 at 1:55 AM, Tristan Sloughter wrote: > This is great! And fun. Waiting so long to play with these I had to make a > branch of jsx using maps for objects today: > https://github.com/tsloughter/jsx/tree/maps > > -- > Tristan Sloughter > tristan.sloughter@REDACTED > > > > On Fri, Oct 25, 2013, at 07:22 PM, Daniel Goertzen wrote: > > Works like a charm! > > Yamler (Erlang yaml file loader) now constructs yaml mappings as erlang > maps. I updated the README examples to show these maps in action: > > https://github.com/goertzenator/yamler/tree/mapping_as_map > > > Thanks for maps! > Dan. > > > On Fri, Oct 25, 2013 at 11:37 AM, Bj?rn-Egil Dahlberg > wrote: > > > Hi! > > Here you go, Maps! > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > To get the branch, > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > or find it at > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > I want to state the following so there is no room for uncertainty: > - This branch contains a development stage of the experimental Maps feature > for Erlang. > > This means: > - Do not use it in production since it is not stable, > - Do not base any git branch on this branch since it will most likely be > rebased, > - and finally, we reserve the right to change any API or interfaces to Maps > currently implemented. > > The implementation is based on EEP 43 - Maps, see > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. > > What is implemented? > > The maps module API and erlang guard BIFs as defined in the EEP are > implemented. There are however some sematic mismatches with the EEP. I think > those are where the definition contradict itself. For instance maps:is_key/1 > compares with =:= as stated first in the definition but the later example > uses lists:keymember which compares with ==. > > The syntax and all what that entails is implemented. The compiler will > handle the map syntax and produce loadable beam-code. I believe this is what > people want to test and is what I want people to test. Test the usability > that is. > > I recommend people look at the EEP for information and also the testsuite > located at erts/emulator/test/map_SUITE.erl for information on how to use > Maps since no other documentation is available. > > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > > Where the operator '=>' (assoc operator) is used for extending and creating > new Maps and the operator ':=' is used to update existing key/values. The > ':=' operator is the only operator allowed in patterns. I'm guessing some > confusion will arise from these two types of operators on where you can > and/or should use them. > > Look at the tests and EEP for details and inspiration. > > A major difference from the EEP are variables in keys. Variables in keys are > not allowed at all. This is because we want to reduce the scope for this > first stage. Plenty to do besides that. > > Here are some additional disclaimers to make people sad. > > What is not implemented? > > - No variable keys. > - No single value access. > - No map comprehensions. > - No datastructure to handle large Maps. > - No MatchSpecs which uses the Maps syntax will work. > > Known issues > > - Dialyzer will not work with maps in the code, this include PLT building > with erts and stdlib. > - HiPE, the native compiler, will not with maps code. > - EDoc will not work with maps. > > I'm sure there are other issues as well, it is a development branch after > all. =) > > I would also like to point out that no optimizations are done either with > respect to the generated code. This means that the instruction set may > change. We know of several optimization we want to do before R17, especially > for the match compiler so keep that in mind. > > We will continue stabilizing the Maps implementation as we move forward > towards R17 and take appropriate action depending on the feedback you give > us. > > I would like to continue with saying a few words about possible changes that > we are thinking about. > > Variables in Keys > > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys is > the one most likely to be dropped if we get pressed for time. Meaning, it > might not be implemented for R17 but instead implemented for R18. The plan > right now is to keep it though. > > The External Format > > The current external format needs ordered keys as input for binary_to_term/1 > and in distribution. > > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I instead > propose that the external format should handle unordered input of key-value > pairs. The trade off is a more complicated decoding which will take longer. > > The distribution format should also be extended to be able cache keys. This > is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all along > but it not mentioned in the EEP. > > Term order and sorting > > Finally the term order. This has been a sore point from the get go. > > Maps currently respects the Erlang term order for it's keys. > > The Erlang term order is what I call arithmetic term order. I propose that > we extend Erlang with true term order where integer compares less then > float, i.e. total term order. > > This would allowing newer ordered data structures, like maps, to be more > useful. We don't have to take > special care for the odd cases like keys 1.0 and 1 inhabiting the same slot > in the data structure. gb_trees and such structures could also be extended > to use this as those structures has the same limitations. > > With this type ordering we could have maps with this type of keys, #{ 1 => > "integer", 1.0 => "float" } without causing confusion. > > I've been told that ETS ordered sets tables used to have this behaviour. > Distinguishing between floats and integers. This was supposedly before the > open source era, way back when dinosaurs roamed the planet .. I'm not clear > on the details on why this behaviour was removed. Probably because of > inconsistencies. > > For maps to work with this I only need two things. First, a compare > operation in the runtime that can distinguish between floats and integers, > very easy. Secondly, a BIF that sort a list of terms with this new compare > operation which will be used in the compiler. > > But for completness, the following operators should also be implemented: > > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > > So, true = 1 <:< 1.0. > > I don't know prolog but perhaps these sematics should mimic prolog to > respect Erlangs heritage. I have no strong opinion on this. > > This syntax would mimic the already present =:= and =/= relational operators > hower this syntax is another topic and should be a seperate EEP. > > Happy testing! > > Regards, > Bj?rn-Egil Dahlberg > Erlang/OTP > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From freza@REDACTED Sun Oct 27 15:58:55 2013 From: freza@REDACTED (Jachym Holecek) Date: Sun, 27 Oct 2013 10:58:55 -0400 Subject: [erlang-questions] more random uniform In-Reply-To: References: <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> Message-ID: <20131027145854.GA11202@circlewave.net> # Bengt Kleberg 2013-10-27: > > 7> [erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Looking at how uniform/0 and uniform/1 work -- with the seed you're supplying all factors in calculation of R end up something like 0.05, giving R of say 0.16, mapping to (0,1) range is a no-op, times three in uniform/1 resulting firmly less than 1.0, truncating to zero, adding one and yielding the ones you're observing. OTP version doesn't really matter, same results with R11 up to R16, random(3) probably didn't change drastically over time. Initializing the seed manually, other than the recommended way, so it gives good results from the start is beginning to sound a bit tricky... BR, -- Jachym From donpedrothird@REDACTED Sun Oct 27 16:35:21 2013 From: donpedrothird@REDACTED (Evgeny M) Date: Sun, 27 Oct 2013 08:35:21 -0700 (PDT) Subject: [erlang-questions] more random uniform In-Reply-To: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com> References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com> Message-ID: <74d5ebee-a8c0-4fbf-bb89-9c751b0bee6e@googlegroups.com> 1> [erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 BUT (now() instead of X, y, 0) 2> [erlang:spawn( fun() -> random:seed(now()), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. 1 3 3 2 3 1 2 1 2 3 1 3 1 2 1 3 3 1 1 3 2 1 2 1 3 1 3 2 3 2 3 2 3 1 2 3 2 3 1 2 3 2 1 3 1 2 1 2 1 1 1 1 2 2 3 1 2 3 1 3 2 1 2 3 2 1 3 1 2 1 3 3 2 2 1 3 3 1 2 1 2 2 2 1 1 2 3 2 3 1 2 3 1 3 1 2 3 2 3 2 ???????????, 27 ??????? 2013 ?., 13:45:35 UTC+4 ???????????? Bengt Kleberg ???????: > > Greetings, > > When doing random:uniform/1 for small values, ie 3, the result is 1 the > first time. Changing the seed does not help. > What am I missing? > > > Bengt > > Sent from Moxier Mail > (http://www.moxier.com) > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Sun Oct 27 17:28:24 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 27 Oct 2013 16:28:24 +0000 Subject: [erlang-questions] more random uniform In-Reply-To: <74d5ebee-a8c0-4fbf-bb89-9c751b0bee6e@googlegroups.com> References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com>, <74d5ebee-a8c0-4fbf-bb89-9c751b0bee6e@googlegroups.com> Message-ID: My computer is not available right now, but my understanding is that using now() will make it really hard to reproduce that sequence again. Bengt Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Evgeny M Till: "erlang-programming@REDACTED" Kopia: "erlang-questions@REDACTED" , Bengt Kleberg Skickat: 27-10-2013 4:35 em ?mne: Re: [erlang-questions] more random uniform 1> [erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 BUT (now() instead of X, y, 0) 2> [erlang:spawn( fun() -> random:seed(now()), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. 1 3 3 2 3 1 2 1 2 3 1 3 1 2 1 3 3 1 1 3 2 1 2 1 3 1 3 2 3 2 3 2 3 1 2 3 2 3 1 2 3 2 1 3 1 2 1 2 1 1 1 1 2 2 3 1 2 3 1 3 2 1 2 3 2 1 3 1 2 1 3 3 2 2 1 3 3 1 2 1 2 2 2 1 1 2 3 2 3 1 2 3 1 3 1 2 3 2 3 2 ???????????, 27 ??????? 2013 ?., 13:45:35 UTC+4 ???????????? Bengt Kleberg ???????: Greetings, When doing random:uniform/1 for small values, ie 3, the result is 1 the first time. Changing the seed does not help. What am I missing? Bengt Sent from Moxier Mail (http://www.moxier.com) _______________________________________________ erlang-questions mailing list erlang-q...@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Sun Oct 27 17:39:46 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 27 Oct 2013 16:39:46 +0000 Subject: [erlang-questions] more random uniform In-Reply-To: <20131027145854.GA11202@circlewave.net> References: <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> , <20131027145854.GA11202@circlewave.net> Message-ID: <6n3epy2pjkdt7w18nb70qskn.1382891983908@email.android.com> Would it be better to use seed(O,X,Y) than seed(X,Y,O)? Or should I multiply them larger? Bengt Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Jachym Holecek Till: Bengt Kleberg Kopia: "erlang-questions@REDACTED" Skickat: 27-10-2013 3:56 em ?mne: Re: [erlang-questions] more random uniform # Bengt Kleberg 2013-10-27: > > 7> [erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Looking at how uniform/0 and uniform/1 work -- with the seed you're supplying all factors in calculation of R end up something like 0.05, giving R of say 0.16, mapping to (0,1) range is a no-op, times three in uniform/1 resulting firmly less than 1.0, truncating to zero, adding one and yielding the ones you're observing. OTP version doesn't really matter, same results with R11 up to R16, random(3) probably didn't change drastically over time. Initializing the seed manually, other than the recommended way, so it gives good results from the start is beginning to sound a bit tricky... BR, -- Jachym From freza@REDACTED Sun Oct 27 18:15:17 2013 From: freza@REDACTED (Jachym Holecek) Date: Sun, 27 Oct 2013 13:15:17 -0400 Subject: [erlang-questions] more random uniform In-Reply-To: <6n3epy2pjkdt7w18nb70qskn.1382891983908@email.android.com> References: <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> <6n3epy2pjkdt7w18nb70qskn.1382891983908@email.android.com> Message-ID: <20131027171517.GA13255@circlewave.net> # Bengt Kleberg 2013-10-27: > Would it be better to use seed(O,X,Y) than seed(X,Y,O)? > Or should I multiply them larger? Here's three attempts that look encouraging (note I can't really justify their validity): %% A1 large modulo Prime1, A2 small module Prime2, A3 noisy. 25> rp([begin random:seed(30269 - X, 30307 + X, erlang:phash2(X)), random:uniform(3) end || X <- lists:seq(1, 100)]). [1,3,2,3,3,3,3,2,1,3,3,1,3,2,3,1,3,1,1,2,1,3,3,1,1,3,2,1,2, 3,2,1,1,3,2,1,1,3,3,2,3,1,3,3,2,2,1,1,1,1,3,3,2,2,3,3,3,2,2, 2,3,1,2,1,3,3,3,3,1,2,1,1,2,3,3,2,2,3,2,2,3,3,2,1,2,1,3,1,1, 1,1,1,3,1,3,2,3,1,3,3] %% All components quite large and noisy. 26> rp([begin random:seed(erlang:phash2(X), erlang:phash2(X + 1), erlang:phash2(X + 3)), random:uniform(3) end || X <- lists:seq(1, 100)]). [2,2,2,1,3,3,2,1,1,1,1,2,2,2,3,3,3,1,3,2,3,2,1,2,1,3,3,1,1, 3,1,2,3,1,1,3,2,3,1,2,1,3,1,2,2,2,1,3,1,1,1,3,3,2,1,2,2,1,3, 2,1,3,2,2,2,2,3,1,3,3,2,3,3,1,3,2,1,1,1,2,2,2,2,2,1,1,1,3,1, 2,3,2,1,2,2,1,2,3,2,1] %% Playing around with actual now() constant, avoiding phash2(). 27> rp([begin random:seed(1382, 896041, 690123 + (16384*X)), random:uniform(3) end || X <- lists:seq(1, 100)]). [3,2,3,2,1,2,1,3,1,3,1,3,2,3,2,1,2,1,2,1,3,1,3,2,3,2,3,2,1, 2,1,2,1,3,1,3,2,3,2,3,2,1,2,1,3,1,3,1,3,2,3,2,1,2,1,2,1,3,1, 3,1,3,2,3,2,1,2,1,2,1,3,1,3,2,3,2,3,2,1,2,1,3,1,3,1,3,2,3,2, 3,2,1,2,1,3,1,3,1,3,2] You seem to have two deterministic parameters available, that should be handy. In the last case note that just incrementing A3, as now() would, didn't work very well -- shifting by 16 bits helped. HTH, -- Jachym From tony@REDACTED Sun Oct 27 18:14:27 2013 From: tony@REDACTED (Tony Rogvall) Date: Sun, 27 Oct 2013 18:14:27 +0100 Subject: [erlang-questions] more random uniform In-Reply-To: References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com>, , <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> Message-ID: No it was not necessary, just making sure it was fresh every time. Any particular reason to keep the third argument to zero in the random:seed/3 call ? This will, as you point out, generate an initial sequence of small random:uniform numbers. Looking at random.erl the calculation is (modified in this context): (((X+1)*171) rem 30269) / 30269 + (((Y+1)*172) rem 30307) / 30307 + (((0+1)*170) rem 30323) / 30323 Keeping the X and Y small enough (less than 176 ) we can rewrite this as: R = ((X+1)*171) / 30269 + ((Y+1)*172) / 30307 + 170 / 30323 The value of this expression will be small given small values on X and Y, and the expression trunc(R*3) will be zero for X+Y < 56 (roughly) In other words use larger numbers, and use them all, when seeding the random number generator. /Tony On 27 okt 2013, at 11:48, Bengt Kleberg wrote: > 7> [erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > > > Sent from Moxier Mail > (http://www.moxier.com) > > > ----- Ursprungligt meddelande ----- > Fr?n: Bengt Kleberg > Till: null > Kopia: "erlang-questions@REDACTED" > Skickat: 27-10-2013 11:33 fm > ?mne: Re: [erlang-questions] more random uniform > > > Thank you. > > I have 15B. > Is the erase/1 necessary? I am using new processes each time. > > > Bengt > > Sent from Moxier Mail > (http://www.moxier.com) > > > ----- Ursprungligt meddelande ----- > Fr?n: Tony Rogvall > Till: Bengt Kleberg > Kopia: "erlang-questions@REDACTED" > Skickat: 27-10-2013 11:13 fm > ?mne: Re: [erlang-questions] more random uniform > > > I can not replicate this (on R16B01). > > > erase(random_seed), random:seed(erlang:now()), random:uniform(3). > 1 > > erase(random_seed), random:seed(erlang:now()), random:uniform(3). > 2 > ... > > ? > > /Tony > > > On 27 okt 2013, at 10:45, Bengt Kleberg wrote: > >> Greetings, >> >> When doing random:uniform/1 for small values, ie 3, the result is 1 the first time. Changing the seed does not help. >> What am I missing? >> >> >> Bengt >> >> Sent from Moxier Mail >> (http://www.moxier.com) >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Sun Oct 27 18:15:19 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Sun, 27 Oct 2013 18:15:19 +0100 (CET) Subject: [erlang-questions] ssl server multiple certificates In-Reply-To: References: Message-ID: <853116095.697297.1382894119485.JavaMail.zimbra@tpip.net> Hi Sergej, No, it's not possible. A few ideas on how to add it: To do that Erlang SSL would need to support the SNI (Server Name Indication) TLS Extensions (RFC 3546). Currently neither in client nor in server mode that extension is supported. Adding it for client mode should be relatively simple, just add a ssl option to pass the server name to the library and include that into a SNI hello extension. For server mode, things are a bit more complicated. Basically every option that's in the ssloption() type needs to be made a per server option with the server name as selector. Decoding the client hello extension again is simple, then a look up of the options per server name and you're done. The extended options could be something like this: in server mode: {sni, ServerName:string(), Options:ssloptions()} in client mode: {sni, ServerName:string()} Andreas ----- Original Message ----- > hello, > > Is it possible to host multiple ssl certificates for different domains on a > single IP and port? Like nginx is capable of doing. > > > Sergej > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From n.oxyde@REDACTED Sun Oct 27 20:01:31 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 27 Oct 2013 20:01:31 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> Message-ID: <00562DD2-1883-4CBF-9FC5-48E01700B517@gmail.com> You should put the function call into parenthesis. Anyway I don?t see why that should be allowed without parenthesis, you can?t do foo()#bar either, right? And why would you throw away a result you just computed to only use a subpart of it? -- Anthony Ramine Le 26 oct. 2013 ? 22:46, Pierre Fenoll a ?crit : > What that means is that one can't query maps directly from a function's output. It just would not compile. > From n.oxyde@REDACTED Sun Oct 27 20:04:57 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 27 Oct 2013 20:04:57 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <003801ced259$b9b60840$2d2218c0$@frcuba.co.cu> Message-ID: <5316C594-11FB-4F1F-86BB-428E6E1B6795@gmail.com> Probably a missing safe/2 call somewhere in v3_core :) -- Anthony Ramine Le 27 oct. 2013 ? 00:17, Bj?rn-Egil Dahlberg a ?crit : > Apparently it only handle variables .. =) I will look into this during the week. > From n.oxyde@REDACTED Sun Oct 27 20:09:23 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 27 Oct 2013 20:09:23 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <1382831743.2822.39046341.5B53957E@webmail.messagingengine.com> Message-ID: <46610BD9-0299-48CB-873A-2D3DDD40BA89@gmail.com> Abstract modules don?t exist. The leftover from pmods is a really ugly hack where you can do an external call with a tuple as a module. As for my thoughts: no. What is the point of such an indirection? Why do you need to abstract over multiple implementations? Choose an adequate data structure for your domain problem and stick with it or change it if you find a better implementation. Regards, -- Anthony Ramine Le 27 oct. 2013 ? 11:58, Gleb Peregud a ?crit : > Great work, OTP team! > > I was wondering about one thing. I find abstract modules (a leftover > of parametrized modules) a very neat feature in some cases and I was > wondering if anyone else would like to be able to something like this > with maps: > > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M0:put("key", Value3), % mapped to maps:put("key", Value3, M0) > M2 = M1:put(<<"key">>, Value4) > > Do you think this is a desirable feature? It can be useful for > creating some kind of abstraction layer over multiple implementations > of the same interface without having to use macros nor implementing a > proxy modules to handle this. > > Thoughts? > > Cheers, > Gleb > > On Sun, Oct 27, 2013 at 1:55 AM, Tristan Sloughter > wrote: >> This is great! And fun. Waiting so long to play with these I had to make a >> branch of jsx using maps for objects today: >> https://github.com/tsloughter/jsx/tree/maps >> >> -- >> Tristan Sloughter >> tristan.sloughter@REDACTED >> >> >> >> On Fri, Oct 25, 2013, at 07:22 PM, Daniel Goertzen wrote: >> >> Works like a charm! >> >> Yamler (Erlang yaml file loader) now constructs yaml mappings as erlang >> maps. I updated the README examples to show these maps in action: >> >> https://github.com/goertzenator/yamler/tree/mapping_as_map >> >> >> Thanks for maps! >> Dan. >> >> >> On Fri, Oct 25, 2013 at 11:37 AM, Bj?rn-Egil Dahlberg >> wrote: >> >> >> Hi! >> >> Here you go, Maps! >> >> I've pushed a Maps branch to Erlang/OTPs repository at GitHub. >> >> To get the branch, >> >> git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation >> >> or find it at >> https://github.com/erlang/otp/tree/egil/maps/eep-implementation >> >> I want to state the following so there is no room for uncertainty: >> - This branch contains a development stage of the experimental Maps feature >> for Erlang. >> >> This means: >> - Do not use it in production since it is not stable, >> - Do not base any git branch on this branch since it will most likely be >> rebased, >> - and finally, we reserve the right to change any API or interfaces to Maps >> currently implemented. >> >> The implementation is based on EEP 43 - Maps, see >> http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. >> >> What is implemented? >> >> The maps module API and erlang guard BIFs as defined in the EEP are >> implemented. There are however some sematic mismatches with the EEP. I think >> those are where the definition contradict itself. For instance maps:is_key/1 >> compares with =:= as stated first in the definition but the later example >> uses lists:keymember which compares with ==. >> >> The syntax and all what that entails is implemented. The compiler will >> handle the map syntax and produce loadable beam-code. I believe this is what >> people want to test and is what I want people to test. Test the usability >> that is. >> >> I recommend people look at the EEP for information and also the testsuite >> located at erts/emulator/test/map_SUITE.erl for information on how to use >> Maps since no other documentation is available. >> >> Roughly, >> M0 = #{ key => Value1, "key" => Value2}, % for construction. >> M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates >> #{ "key" := V } = M1. % for matching >> >> Where the operator '=>' (assoc operator) is used for extending and creating >> new Maps and the operator ':=' is used to update existing key/values. The >> ':=' operator is the only operator allowed in patterns. I'm guessing some >> confusion will arise from these two types of operators on where you can >> and/or should use them. >> >> Look at the tests and EEP for details and inspiration. >> >> A major difference from the EEP are variables in keys. Variables in keys are >> not allowed at all. This is because we want to reduce the scope for this >> first stage. Plenty to do besides that. >> >> Here are some additional disclaimers to make people sad. >> >> What is not implemented? >> >> - No variable keys. >> - No single value access. >> - No map comprehensions. >> - No datastructure to handle large Maps. >> - No MatchSpecs which uses the Maps syntax will work. >> >> Known issues >> >> - Dialyzer will not work with maps in the code, this include PLT building >> with erts and stdlib. >> - HiPE, the native compiler, will not with maps code. >> - EDoc will not work with maps. >> >> I'm sure there are other issues as well, it is a development branch after >> all. =) >> >> I would also like to point out that no optimizations are done either with >> respect to the generated code. This means that the instruction set may >> change. We know of several optimization we want to do before R17, especially >> for the match compiler so keep that in mind. >> >> We will continue stabilizing the Maps implementation as we move forward >> towards R17 and take appropriate action depending on the feedback you give >> us. >> >> I would like to continue with saying a few words about possible changes that >> we are thinking about. >> >> Variables in Keys >> >> This feature is actually furthest down on the work prio list. We want to >> stabilize the current features before moving forward and variable keys is >> the one most likely to be dropped if we get pressed for time. Meaning, it >> might not be implemented for R17 but instead implemented for R18. The plan >> right now is to keep it though. >> >> The External Format >> >> The current external format needs ordered keys as input for binary_to_term/1 >> and in distribution. >> >> This is of course an inconvinience when dealing with other language >> interfaces which has no idea of what the erlang term order is. I instead >> propose that the external format should handle unordered input of key-value >> pairs. The trade off is a more complicated decoding which will take longer. >> >> The distribution format should also be extended to be able cache keys. This >> is similar to the atom cache except we >> cache the entire key array for maps. This has been the intention all along >> but it not mentioned in the EEP. >> >> Term order and sorting >> >> Finally the term order. This has been a sore point from the get go. >> >> Maps currently respects the Erlang term order for it's keys. >> >> The Erlang term order is what I call arithmetic term order. I propose that >> we extend Erlang with true term order where integer compares less then >> float, i.e. total term order. >> >> This would allowing newer ordered data structures, like maps, to be more >> useful. We don't have to take >> special care for the odd cases like keys 1.0 and 1 inhabiting the same slot >> in the data structure. gb_trees and such structures could also be extended >> to use this as those structures has the same limitations. >> >> With this type ordering we could have maps with this type of keys, #{ 1 => >> "integer", 1.0 => "float" } without causing confusion. >> >> I've been told that ETS ordered sets tables used to have this behaviour. >> Distinguishing between floats and integers. This was supposedly before the >> open source era, way back when dinosaurs roamed the planet .. I'm not clear >> on the details on why this behaviour was removed. Probably because of >> inconsistencies. >> >> For maps to work with this I only need two things. First, a compare >> operation in the runtime that can distinguish between floats and integers, >> very easy. Secondly, a BIF that sort a list of terms with this new compare >> operation which will be used in the compiler. >> >> But for completness, the following operators should also be implemented: >> >> =:= term exact equal to, already implemented >> =/= term not equal to, already implemented >> =:< term less or equal than >>> := term greater or equal than >> <:< term less than >>> :> term greater than >> >> So, true = 1 <:< 1.0. >> >> I don't know prolog but perhaps these sematics should mimic prolog to >> respect Erlangs heritage. I have no strong opinion on this. >> >> This syntax would mimic the already present =:= and =/= relational operators >> hower this syntax is another topic and should be a seperate EEP. >> >> Happy testing! >> >> Regards, >> Bj?rn-Egil Dahlberg >> Erlang/OTP >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From sergej.jurecko@REDACTED Sun Oct 27 20:10:58 2013 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Sun, 27 Oct 2013 20:10:58 +0100 Subject: [erlang-questions] ssl server multiple certificates In-Reply-To: <853116095.697297.1382894119485.JavaMail.zimbra@tpip.net> References: <853116095.697297.1382894119485.JavaMail.zimbra@tpip.net> Message-ID: <947F4833-89AF-43C8-8824-E865860F58A7@gmail.com> Thank you very much for the info. Looks simpler than I thought. Sergej On Oct 27, 2013, at 6:15 PM, Andreas Schultz wrote: > Hi Sergej, > > No, it's not possible. > > A few ideas on how to add it: > > To do that Erlang SSL would need to support the SNI (Server Name Indication) > TLS Extensions (RFC 3546). Currently neither in client nor in server mode > that extension is supported. > Adding it for client mode should be relatively simple, just add a ssl option > to pass the server name to the library and include that into a SNI hello > extension. > For server mode, things are a bit more complicated. Basically every option > that's in the ssloption() type needs to be made a per server option with > the server name as selector. Decoding the client hello extension again is > simple, then a look up of the options per server name and you're done. > > The extended options could be something like this: > in server mode: {sni, ServerName:string(), Options:ssloptions()} > in client mode: {sni, ServerName:string()} > > Andreas > > ----- Original Message ----- >> hello, >> >> Is it possible to host multiple ssl certificates for different domains on a >> single IP and port? Like nginx is capable of doing. >> >> >> Sergej >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > -- > Dipl. Inform. > Andreas Schultz > > email: as@REDACTED > phone: +49-391-819099-224 > mobil: +49-170-2226073 > > ------------------- enabling your networks ------------------- > > Travelping GmbH phone: +49-391-819099229 > Roentgenstr. 13 fax: +49-391-819099299 > D-39108 Magdeburg email: info@REDACTED > GERMANY web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 > -------------------------------------------------------------- From bengt.kleberg@REDACTED Sun Oct 27 20:36:01 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 27 Oct 2013 19:36:01 +0000 Subject: [erlang-questions] more random uniform In-Reply-To: References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com>, , <0i41xd7ay77hnpix398boak9.1382870007723@email.android.com> , Message-ID: <3dfb5gr1s2155dhb8b2dmix3.1382902558885@email.android.com> Thank you all. By using X*1000, Y*1000 and the sum *1000 I got sufficiently random numbers. Bengt Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Tony Rogvall Till: Bengt Kleberg Kopia: "erlang-questions@REDACTED" Skickat: 27-10-2013 6:14 em ?mne: Re: [erlang-questions] more random uniform No it was not necessary, just making sure it was fresh every time. Any particular reason to keep the third argument to zero in the random:seed/3 call ? This will, as you point out, generate an initial sequence of small random:uniform numbers. Looking at random.erl the calculation is (modified in this context): (((X+1)*171) rem 30269) / 30269 + (((Y+1)*172) rem 30307) / 30307 + (((0+1)*170) rem 30323) / 30323 Keeping the X and Y small enough (less than 176 ) we can rewrite this as: R = ((X+1)*171) / 30269 + ((Y+1)*172) / 30307 + 170 / 30323 The value of this expression will be small given small values on X and Y, and the expression trunc(R*3) will be zero for X+Y < 56 (roughly) In other words use larger numbers, and use them all, when seeding the random number generator. /Tony On 27 okt 2013, at 11:48, Bengt Kleberg > wrote: 7> [erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)]. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Bengt Kleberg > Till: null Kopia: "erlang-questions@REDACTED" > Skickat: 27-10-2013 11:33 fm ?mne: Re: [erlang-questions] more random uniform Thank you. I have 15B. Is the erase/1 necessary? I am using new processes each time. Bengt Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Tony Rogvall > Till: Bengt Kleberg > Kopia: "erlang-questions@REDACTED" > Skickat: 27-10-2013 11:13 fm ?mne: Re: [erlang-questions] more random uniform I can not replicate this (on R16B01). > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 1 > erase(random_seed), random:seed(erlang:now()), random:uniform(3). 2 ... ? /Tony On 27 okt 2013, at 10:45, Bengt Kleberg > wrote: Greetings, When doing random:uniform/1 for small values, ie 3, the result is 1 the first time. Changing the seed does not help. What am I missing? Bengt Sent from Moxier Mail (http://www.moxier.com) _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferenc.holzhauser@REDACTED Mon Oct 28 09:17:12 2013 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Mon, 28 Oct 2013 09:17:12 +0100 Subject: [erlang-questions] Weird problem with "receive after ..." In-Reply-To: <9CFC8C5C-6C15-40C4-8940-34284E58BE0E@samplonius.org> References: <9CFC8C5C-6C15-40C4-8940-34284E58BE0E@samplonius.org> Message-ID: Hi, Thank you all for the help. Updated to Virtualbox 4.3.0 and added the "keepalive" loop to my app. The VM is running very stable now. Regards, Ferenc On 23 October 2013 03:56, Tom Samplonius wrote: > On 2013-10-18, at 1:29 PM, Ferenc Holzhauser > wrote: > > Hi Anthony, > > That must be it: it is running in virtualbox indeed. Are you aware of any > workaround/fix to try? I'm quite attached to this VM setup. Would be great > if I could make it work reliably. > > Ferenc > > > You may want to try Virtualbox 4.3.0, released a few days. This is > listed in the release notes for 4.30: > > * VMM: major rewrite of the VT-x code and the AMD-V code including many > bug fixes and performance improvements (for example > https://www.virtualbox.org/ticket/9659) > > > > > Tom > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Mon Oct 28 09:28:51 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Mon, 28 Oct 2013 09:28:51 +0100 Subject: [erlang-questions] ssl server multiple certificates In-Reply-To: References: Message-ID: Hi! If I remember correctly someone worked on a contribution for this, but I where in the middle of refactoring things and I think it was not quite finished. Since then I have not had time to follow up on it. I think it would not be too hard to add support for it, but it is not our priority at the moment, so please feel free to contribute. And it is quite ok to send in a "pre-patch" to get feed back on API choices before you make the patch conform to all patch requirements. Regards Ingela Erlang/OTP team - Ericssson AB 2013/10/25 Sergej Jurecko > hello, > > Is it possible to host multiple ssl certificates for different domains on > a single IP and port? Like nginx is capable of doing. > > > Sergej > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagarg@REDACTED Mon Oct 28 09:42:17 2013 From: sagarg@REDACTED (Sagun Garg) Date: Mon, 28 Oct 2013 14:12:17 +0530 Subject: [erlang-questions] Fwd: Integration Strategy : Neo4j & Erlang/OTP COMPATIBILITY In-Reply-To: References: Message-ID: Hi, We WISH to use Neo4j with Erlang/OTP in Programming agnostic fashion, two strategies are candidates, need to compare Tinkerpop Blueprint [REST] (Vs) Jinterface [Java Package] Please Advise, I am struggling with a right direction on this issue? Wish to host Neo4j and Erlang/OTP on separate machines ( Remotely Accessing the Database) Cheers Sagun Garg Entrepreneur, Real Estate Transactions, India -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Mon Oct 28 11:29:30 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Mon, 28 Oct 2013 11:29:30 +0100 (CET) Subject: [erlang-questions] ssl server multiple certificates In-Reply-To: References: Message-ID: <1229359405.703226.1382956170048.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > Hi! > > If I remember correctly someone worked on a contribution for this, but I > where in the middle of refactoring > things and I think it was not quite finished. Found it: http://erlang.org/pipermail/erlang-patches/2012-May/002787.html And copied the original author... would be nice to have this in R17 Andreas > Since then I have not had time > to follow up on it. I think it would > not be too hard to add support for it, but it is not our priority at the > moment, so please feel free to contribute. > And it is quite ok to send in a "pre-patch" to get feed back on API choices > before you make the patch conform to all patch requirements. > > Regards Ingela Erlang/OTP team - Ericssson AB > > > 2013/10/25 Sergej Jurecko < sergej.jurecko@REDACTED > > > > hello, > > Is it possible to host multiple ssl certificates for different domains on a > single IP and port? Like nginx is capable of doing. > > > Sergej > _______________________________________________ > 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 > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From peerst@REDACTED Mon Oct 28 14:17:04 2013 From: peerst@REDACTED (Peer Stritzinger) Date: Mon, 28 Oct 2013 14:17:04 +0100 Subject: [erlang-questions] more random uniform References: <2u2appcclpxq22jnjrwirhj2.1382867133155@email.android.com> <74d5ebee-a8c0-4fbf-bb89-9c751b0bee6e@googlegroups.com> Message-ID: If you want to reproduce a sequence you usually store the seed values. One often seen way to properly do random:seed/1 calls: <> = crypto:rand_bytes(12), random:seed({A,B,C}) Save the values of A, B and C in your data (e.g. beginning of the corresponding log or whatever) Cheers -- Peer On 2013-10-27 16:28:24 +0000, Bengt Kleberg said: > My computer is not available right now, but my understanding is that > using now() will make it really hard to reproduce that sequence again. > > > > Bengt > > > Sent from Moxier Mail > (http://www.moxier.com) > > > ----- Ursprungligt meddelande ----- > Fr?n: Evgeny M > Till: "erlang-programming@REDACTED" > > Kopia: "erlang-questions@REDACTED" , > Bengt Kleberg > Skickat: 27-10-2013 4:35 em > ?mne: Re: [erlang-questions] more random uniform > > > 1> ?[erlang:spawn( fun() -> random:seed(X,Y,0), io:fwrite("~p ", > [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)].? > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1? > > BUT (now() instead of X, y, 0) > > 2> ?[erlang:spawn( fun() -> random:seed(now()), io:fwrite("~p ", > [random:uniform(3)]) end ) || X<-lists:seq(1,10), Y<-lists:seq(1,10)].? > 1 3 3 2 3 1 2 1 2 3 1 3 1 2 1 3 3 1 1 3 2 1 2 1 3 1 3 2 3 2 3 2 3 1 2 3 > 2 3 1 2 3 2 1 3 1 2 1 2 1 1 1 1 2 2 3 1 2 3 1 3 2 1 2 3 2 1 3 1 2 1 3 3 > 2 2 1 3 3 1 2 1 2 2 2 1 1 2 3 2 3 1 2 3 1 3 1 2 3 2 3 2? > > > > ???????????, 27 ??????? 2013??., 13:45:35 UTC+4 ???????????? Bengt > Kleberg ???????: > Greetings, > > When doing random:uniform/1 for small values, ie 3, the result is 1 the > first time. Changing the seed does not help. > What am I missing? > > > Bengt > > Sent from Moxier Mail > (http://www.moxier.com) > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Mon Oct 28 16:01:08 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 28 Oct 2013 16:01:08 +0100 Subject: [erlang-questions] erlang related patents Message-ID: Hello, I have been asked to produce a list of patents that "arise from Erlang." By this I mean patents that are somehow dependent upon, or use ideas derived from Erlang. If anybody knows of such patents could they please mail me, with references to these patents Thanks /Joe From robert.virding@REDACTED Mon Oct 28 16:48:47 2013 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 28 Oct 2013 16:48:47 +0100 (CET) Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Great! But I do have some comments (of course): - I would keep the function names from the dict module where possible. This to make it easier to convert. - I definitely agree about creating true term ordering comparison operators to complement =:= and =/=. But as I am more used to the prolog set (@==, @/=, @>, @>=, @< and @=<) I would much prefer to have them instead. They at least start with the same character. Anyway create the operators and define maps to use them, and then fix dict/orddict/gb_trees to use them as well so they are compatible. I could survive potential backwards compatibility problems with them to achieve consistency. - I also definitely agree to keep the syntactic footprint to a minimum and introduce as little new syntax as possible. - For map comprehensions I would NOT use <- as the generator operator as it tells me we are generating elements from a list. Binaries got a new operator and I think maps should as well, for example <:, or something else. Robert ----- Original Message ----- > From: "Bj?rn-Egil Dahlberg" > Hi! > Here you go, Maps! > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > To get the branch, > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > or find it at https://github.com/erlang/otp/tree/egil/maps/eep-implementation > I want to state the following so there is no room for uncertainty: > - This branch contains a development stage of the experimental Maps feature > for Erlang. > This means: > - Do not use it in production since it is not stable, > - Do not base any git branch on this branch since it will most likely be > rebased, > - and finally, we reserve the right to change any API or interfaces to Maps > currently implemented. > The implementation is based on EEP 43 - Maps, see > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md , for details. > What is implemented? > The maps module API and erlang guard BIFs as defined in the EEP are > implemented. There are however some sematic mismatches with the EEP. I think > those are where the definition contradict itself. For instance maps:is_key/1 > compares with =:= as stated first in the definition but the later example > uses lists:keymember which compares with ==. > The syntax and all what that entails is implemented. The compiler will handle > the map syntax and produce loadable beam-code. I believe this is what people > want to test and is what I want people to test. Test the usability that is. > I recommend people look at the EEP for information and also the testsuite > located at erts/emulator/test/map_SUITE.erl for information on how to use > Maps since no other documentation is available. > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > Where the operator '=>' (assoc operator) is used for extending and creating > new Maps and the operator ':=' is used to update existing key/values. The > ':=' operator is the only operator allowed in patterns. I'm guessing some > confusion will arise from these two types of operators on where you can > and/or should use them. > Look at the tests and EEP for details and inspiration. > A major difference from the EEP are variables in keys. Variables in keys are > not allowed at all. This is because we want to reduce the scope for this > first stage. Plenty to do besides that. > Here are some additional disclaimers to make people sad. > What is not implemented? > - No variable keys. > - No single value access. > - No map comprehensions. > - No datastructure to handle large Maps. > - No MatchSpecs which uses the Maps syntax will work. > Known issues > - Dialyzer will not work with maps in the code, this include PLT building > with erts and stdlib. > - HiPE, the native compiler, will not with maps code. > - EDoc will not work with maps. > I'm sure there are other issues as well, it is a development branch after > all. =) > I would also like to point out that no optimizations are done either with > respect to the generated code. This means that the instruction set may > change. We know of several optimization we want to do before R17, especially > for the match compiler so keep that in mind. > We will continue stabilizing the Maps implementation as we move forward > towards R17 and take appropriate action depending on the feedback you give > us. > I would like to continue with saying a few words about possible changes that > we are thinking about. > Variables in Keys > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys is > the one most likely to be dropped if we get pressed for time. Meaning, it > might not be implemented for R17 but instead implemented for R18. The plan > right now is to keep it though. > The External Format > The current external format needs ordered keys as input for binary_to_term/1 > and in distribution. > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I instead > propose that the external format should handle unordered input of key-value > pairs. The trade off is a more complicated decoding which will take longer. > The distribution format should also be extended to be able cache keys. This > is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all along > but it not mentioned in the EEP. > Term order and sorting > Finally the term order. This has been a sore point from the get go. > Maps currently respects the Erlang term order for it's keys. > The Erlang term order is what I call arithmetic term order. I propose that we > extend Erlang with true term order where integer compares less then float, > i.e. total term order. > This would allowing newer ordered data structures, like maps, to be more > useful. We don't have to take > special care for the odd cases like keys 1.0 and 1 inhabiting the same slot > in the data structure. gb_trees and such structures could also be extended > to use this as those structures has the same limitations. > With this type ordering we could have maps with this type of keys, #{ 1 => > "integer", 1.0 => "float" } without causing confusion. > I've been told that ETS ordered sets tables used to have this behaviour. > Distinguishing between floats and integers. This was supposedly before the > open source era, way back when dinosaurs roamed the planet .. I'm not clear > on the details on why this behaviour was removed. Probably because of > inconsistencies. > For maps to work with this I only need two things. First, a compare operation > in the runtime that can distinguish between floats and integers, very easy. > Secondly, a BIF that sort a list of terms with this new compare operation > which will be used in the compiler. > But for completness, the following operators should also be implemented: > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > So, true = 1 <:< 1.0. > I don't know prolog but perhaps these sematics should mimic prolog to respect > Erlangs heritage. I have no strong opinion on this. > This syntax would mimic the already present =:= and =/= relational operators > hower this syntax is another topic and should be a seperate EEP. > Happy testing! > Regards, > Bj?rn-Egil Dahlberg > Erlang/OTP > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Oct 28 16:55:24 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 28 Oct 2013 16:55:24 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <1382831743.2822.39046341.5B53957E@webmail.messagingengine.com> Message-ID: On Sun, Oct 27, 2013 at 11:58 AM, Gleb Peregud wrote: > It can be useful for > creating some kind of abstraction layer over multiple implementations > of the same interface without having to use macros nor implementing a > proxy modules to handle this. > I would like to see a feature that allows you to do this. However, I think there are better ways to achieve this. For starters, a way to do modules like in Scheme48 or Standard ML. For Erlang, Scheme48 is definitely a good way forward, since both languages are dynamically typed: http://community.schemewiki.org/?scheme48-module-system Do note some similarity to Joe Armstrong's Erlang2 proposal. There are also some digging going on w.r.t these ideas in the Elixir community. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Mon Oct 28 16:56:02 2013 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 28 Oct 2013 16:56:02 +0100 (CET) Subject: [erlang-questions] What's the proper/right way to run erlang in the background? In-Reply-To: References: <52651984.6000507@gmail.com> Message-ID: <2109930669.349286.1382975762958.JavaMail.zimbra@erlang-solutions.com> Yes, when you start erl with -s or -run options then a separate process is started by init to evaluate these calls. This process then terminates after the calls have completed. In your first version this caused the supervisors to terminate as they were (correctly) started with a start_link. In your second version the added receive meant that that call never returned and hence the start process never terminated. There is a better explanation in http://www.erlang.org/doc/man/init.html . Robert ----- Original Message ----- > From: "fxmy wang" > To: "Michael Scofield" > Cc: erlang-questions@REDACTED > Sent: Saturday, 26 October, 2013 4:02:14 PM > Subject: Re: [erlang-questions] What's the proper/right way to run erlang in > the background? > Could it because that you are using my_supervisor:start_link(), so the > start() function and the top supervisor is linked . > Then once the start() function executes and quits, your top supervisor also > quits. > Then brings your whole application down . > After you added an infinite receive, you block your start() function from > exciting , thus your whole application is ruining fine ? > 2013?10?21? ??9:33? "Michael Scofield" < bayinamine@REDACTED >??? > > Hi all! I'm new to erlang for a few month. > > > Recently I've developed a small pure erlang program, and it runs well in > > the > > shell. Now I want to run it in the background, as a daemon service process > > in the os (mine is Ubuntu 12.04 64bit with R16B). So I googled "run erlang > > without shell", and google gave me some advice: > > > 1. Using escript. -This is what erlang official faq suggested ( > > http://www.erlang.org/faq/how_do_i.html ). > > > 2. erl -detached -s Module Function Args > > > I tried both. As to #1, my escript goes to > > > #!/usr/bin/env escript > > > main(_) -> > > > my_supervisor:start_link(arg1, arg2). > > > I ran it using "nohup ./my-escript &", and it didn't run my code. =( > > > So I went to #2. I was acknowledged that "-s" can only pass 0 or 1 > > argument, > > so I wrapped my supervisor using > > > -module(run). > > > -export([start/0]). > > > start() -> > > > my_supervisor:start_link(arg1, arg2). > > > and ran my code as "erl -detached -s run start". But this was also a dead > > end. > > > I guessed it's because the run:start/0 just returned and finished the > > shell(Is it?), so I added a line to the run:start/0: > > > -module(run). > > > -export([start/0]). > > > start() -> > > > my_supervisor:start_link(arg1, arg2), > > > receive after infinity -> stop end. > > > And executed "erl -detached -s run start", and everything goes fine! > > my_supervisor started to work without the shell! > > > Though the problem "solved", I'm very very confused. > > > 1. Why the "magic line" solved my problem? > > > 2. What exactly is the proper or right way to run an erlang application in > > the background as the command "nohup ... &" does? > > > Thanks in advance! > > > Michael > > > _______________________________________________ > > > 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 Oct 28 17:05:05 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 28 Oct 2013 17:05:05 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: But the right operand of a map generator is a pair with ?:=?, right? I would say this is not too visually ambiguous. I would avoid any ?:? character in the new operator because Jesper once had the idea of introducing strict generators with ?<:-? and ?<:=?, which would not skip items that doesn?t match (e.g. "[ X || {ok, X} <:- [{error,Reason}] ]" would crash). What about <~? Reminiscing of ROK?s frames. -- Anthony Ramine Le 28 oct. 2013 ? 16:48, Robert Virding a ?crit : > - For map comprehensions I would NOT use <- as the generator operator as it tells me we are generating elements from a list. Binaries got a new operator and I think maps should as well, for example <:, or something else. > From jesper.louis.andersen@REDACTED Mon Oct 28 17:07:00 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 28 Oct 2013 17:07:00 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Mon, Oct 28, 2013 at 5:05 PM, Anthony Ramine wrote: > I would avoid any ?:? character in the new operator because Jesper once > had the idea of introducing strict generators with ?<:-? and ?<:=?, which > would not skip items that doesn?t match (e.g. "[ X || {ok, X} <:- > [{error,Reason}] ]" would crash). Yes. It is a problem I have encountered quite often, where the code throws away terms deliberately and you have no way to fix this but to use a standard lists:map/2 call. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Mon Oct 28 17:13:15 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Mon, 28 Oct 2013 16:13:15 +0000 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: IMHO I would love to think of '<-' as a generic generator, which generates elements out of its rhs without any regard to the type. Otherwise '<-' would not be as not-type-specific as most (every?) other operator is, in this dynamic language. I mean, one could also think of tuple-comprehensions (though I don't see why immediately, but I am not all-seeing). Anthony, fcall()#{ k := new_val } for example? Modify a key's value just after a call. Regarding not skipping items in *-comprehensions: well, that's what lists:map/2 is for. Cheers, -- Pierre Fenoll On 28 October 2013 16:07, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Mon, Oct 28, 2013 at 5:05 PM, Anthony Ramine wrote: > >> I would avoid any ?:? character in the new operator because Jesper once >> had the idea of introducing strict generators with ?<:-? and ?<:=?, which >> would not skip items that doesn?t match (e.g. "[ X || {ok, X} <:- >> [{error,Reason}] ]" would crash). > > > Yes. It is a problem I have encountered quite often, where the code throws > away terms deliberately and you have no way to fix this but to use a > standard lists:map/2 call. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Mon Oct 28 17:17:20 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 28 Oct 2013 17:17:20 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: > But the right operand of a map generator is a pair with ?:=?, right? I > would say this is not too visually ambiguous. > I agree with this. The current approach is clear enough compared to the cost that it is to introduce another operator to the comprehension syntax. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Oct 28 17:27:31 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 28 Oct 2013 17:27:31 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: <69943DDF-DB22-4E6F-9ABE-A1D9DB157BE2@gmail.com> ?<-? can?t be used for binary generators so it can?t be generic. And lists:map/2 doesn?t help for non-skipping bit strings generators, nor it helps for bit string comprehensions. -- Anthony Ramine Le 28 oct. 2013 ? 17:13, Pierre Fenoll a ?crit : > IMHO I would love to think of '<-' as a generic generator, which generates elements out of its rhs without any regard to the type. > Otherwise '<-' would not be as not-type-specific as most (every?) other operator is, in this dynamic language. > I mean, one could also think of tuple-comprehensions (though I don't see why immediately, but I am not all-seeing). > > Anthony, fcall()#{ k := new_val } for example? Modify a key's value just after a call. > > Regarding not skipping items in *-comprehensions: well, that's what lists:map/2 is for. > > > Cheers, > -- > Pierre Fenoll > > > > On 28 October 2013 16:07, Jesper Louis Andersen wrote: > > On Mon, Oct 28, 2013 at 5:05 PM, Anthony Ramine wrote: > I would avoid any ?:? character in the new operator because Jesper once had the idea of introducing strict generators with ?<:-? and ?<:=?, which would not skip items that doesn?t match (e.g. "[ X || {ok, X} <:- [{error,Reason}] ]" would crash). > > Yes. It is a problem I have encountered quite often, where the code throws away terms deliberately and you have no way to fix this but to use a standard lists:map/2 call. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From n.oxyde@REDACTED Mon Oct 28 17:28:08 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 28 Oct 2013 17:28:08 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: Though introducing a new operator is no harder than reusing ?<-? in this case. -- Anthony Ramine Le 28 oct. 2013 ? 17:17, Jos? Valim a ?crit : > I agree with this. The current approach is clear enough compared to the cost that it is to introduce another operator to the comprehension syntax. From wallentin.dahlberg@REDACTED Mon Oct 28 20:06:55 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Mon, 28 Oct 2013 20:06:55 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: 2013/10/28 Robert Virding > Great! But I do have some comments (of course): > Great! =) > > - I would keep the function names from the dict module where possible. > This to make it easier to convert. > I agree with your point. Ease of conversion would be great. But, why would dict be more suitable than gb_trees ? The current API is of personal preference ofc. > > - I definitely agree about creating true term ordering comparison > operators to complement =:= and =/=. But as I am more used to the prolog > set (@==, @/=, @>, @>=, @< and @=<) I would much prefer to have them > instead. They at least start with the same character. Anyway create the > operators and define maps to use them, and then fix dict/orddict/gb_trees > to use them as well so they are compatible. I could survive potential > backwards compatibility problems with them to achieve consistency. > I'm thinking of writing another EEP. I did a test implementation of <:<, >:>, =:<, >:= this weekend to see how it would pan out. See, https://github.com/psyeugenic/otp/commits/egil/total-order-relops for details. Seemed ok. The syntax can be changed to suite prolog heritage but the @... syntax freak me out to be honest =) Also what should we do with =:= vs @== and =/= vs @/= in that case? Should we have two operators with the same meaning? > > - I also definitely agree to keep the syntactic footprint to a minimum and > introduce as little new syntax as possible. > Check. > > - For map comprehensions I would NOT use <- as the generator operator as > it tells me we are generating elements from a list. Binaries got a new > operator and I think maps should as well, for example <:, or something else. > There are currently no generator implemented, and it might not be implemented either. Also, I think K := V <- Map works for the visual and it is definitely unique enough to be parsable. The difference of #{ K := V } <- List vs. K := V <- Map might be to subtle though. I think we might have to revisit this and give maps its own arrow. Thank you! //Bj?rn-Egil > > Robert > > > ------------------------------ > > *From: *"Bj?rn-Egil Dahlberg" > > > Hi! > > Here you go, Maps! > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > To get the branch, > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > or find it at > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > I want to state the following so there is no room for uncertainty: > - This branch contains a *development stage* of the *experimental* Maps > feature for Erlang. > > This means: > - Do not use it in production since it is not stable, > - Do not base any git branch on this branch since it will most likely be > rebased, > - and finally, we reserve the right to change any API or interfaces to > Maps currently implemented. > > The implementation is based on EEP 43 - Maps, see > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. > > What is implemented? > > The maps module API and erlang guard BIFs as defined in the EEP are > implemented. There are however some sematic mismatches with the EEP. I > think those are where the definition contradict itself. For instance > maps:is_key/1 compares with =:= as stated first in the definition but the > later example uses lists:keymember which compares with ==. > > The syntax and all what that entails is implemented. The compiler will > handle the map syntax and produce loadable beam-code. I believe this is > what people want to test and is what I want people to test. Test the > usability that is. > > I recommend people look at the EEP for information and also the testsuite > located at erts/emulator/test/map_SUITE.erl for information on how to use > Maps since no other documentation is available. > > Roughly, > M0 = #{ key => Value1, "key" => Value2}, % for construction. > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > #{ "key" := V } = M1. % for matching > > Where the operator '=>' (assoc operator) is used for extending and > creating new Maps and the operator ':=' is used to update existing > key/values. The ':=' operator is the only operator allowed in patterns. I'm > guessing some confusion will arise from these two types of operators on > where you can and/or should use them. > > Look at the tests and EEP for details and inspiration. > > A major difference from the EEP are variables in keys. Variables in keys > are not allowed at all. This is because we want to reduce the scope for > this first stage. Plenty to do besides that. > > Here are some additional disclaimers to make people sad. > > What is not implemented? > > - No variable keys. > - No single value access. > - No map comprehensions. > - No datastructure to handle large Maps. > - No MatchSpecs which uses the Maps syntax will work. > > Known issues > > - Dialyzer will not work with maps in the code, this include PLT building > with erts and stdlib. > - HiPE, the native compiler, will not with maps code. > - EDoc will not work with maps. > > I'm sure there are other issues as well, it is a development branch after > all. =) > > I would also like to point out that no optimizations are done either with > respect to the generated code. This means that the instruction set may > change. We know of several optimization we want to do before R17, > especially for the match compiler so keep that in mind. > > We will continue stabilizing the Maps implementation as we move forward > towards R17 and take appropriate action depending on the feedback you give > us. > > I would like to continue with saying a few words about possible changes > that we are thinking about. > > Variables in Keys > > This feature is actually furthest down on the work prio list. We want to > stabilize the current features before moving forward and variable keys is > the one most likely to be dropped if we get pressed for time. Meaning, it > might not be implemented for R17 but instead implemented for R18. The plan > right now is to keep it though. > > The External Format > > The current external format *needs* ordered keys as input for > binary_to_term/1 and in distribution. > > This is of course an inconvinience when dealing with other language > interfaces which has no idea of what the erlang term order is. I instead > propose that the external format should handle unordered input of key-value > pairs. The trade off is a more complicated decoding which will take longer. > > The distribution format should also be extended to be able cache keys. > This is similar to the atom cache except we > cache the entire key array for maps. This has been the intention all along > but it not mentioned in the EEP. > > Term order and sorting > > Finally the term order. This has been a sore point from the get go. > > Maps currently respects the Erlang term order for it's keys. > > The Erlang term order is what I call arithmetic term order. I propose that > we extend Erlang with true term order where integer compares less then > float, i.e. total term order. > > This would allowing newer ordered data structures, like maps, to be more > useful. We don't have to take > special care for the odd cases like keys 1.0 and 1 inhabiting the same > slot in the data structure. gb_trees and such structures could also be > extended to use this as those structures has the same limitations. > > With this type ordering we could have maps with this type of keys, #{ 1 => > "integer", 1.0 => "float" } without causing confusion. > > I've been told that ETS ordered sets tables used to have this behaviour. > Distinguishing between floats and integers. This was supposedly before the > open source era, way back when dinosaurs roamed the planet .. I'm not clear > on the details on why this behaviour was removed. Probably because of > inconsistencies. > > For maps to work with this I only need two things. First, a compare > operation in the runtime that can distinguish between floats and integers, > very easy. Secondly, a BIF that sort a list of terms with this new compare > operation which will be used in the compiler. > > But for completness, the following operators should also be implemented: > > =:= term exact equal to, already implemented > =/= term not equal to, already implemented > =:< term less or equal than > >:= term greater or equal than > <:< term less than > >:> term greater than > > So, true = 1 <:< 1.0. > > I don't know prolog but perhaps these sematics should mimic prolog to > respect Erlangs heritage. I have no strong opinion on this. > > This syntax would mimic the already present =:= and =/= relational > operators hower this syntax is another topic and should be a seperate EEP. > > Happy testing! > > Regards, > Bj?rn-Egil Dahlberg > Erlang/OTP > > _______________________________________________ > 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 letien83@REDACTED Mon Oct 28 18:37:57 2013 From: letien83@REDACTED (Tien Le) Date: Mon, 28 Oct 2013 18:37:57 +0100 Subject: [erlang-questions] Why netconf_client:get_result Timeout value is not used in its xmerl contiuation_fun? Message-ID: Hi, In the netconf_client.erl code, The user-defined "Timeout" is passed down until it is used in "receive ... after Timeout" expression in netconf_transport:receive_data/2 However during the XML processing step, the continuation_fun called cont/3 uses netconf_transport:receive_data/1 once again, but with "receive ... after infinity" Does it mean that the Timeout which user has entered is not used in the continuation_fun? What happens if the netconf_transport:receive_data/1 takes longer than the "Timeout"? Here is the code snippet: %%%%%%%%%%%%% netconf_client.erl %%%%%%%%%%%%% get_result(Connection, Timeout) -> case *netconf_transport:receive_data(Connection, Timeout)* of {ok, Data} -> case to_simple_xml(Data, Connection) of {'rpc-reply',_Attrs,Result} -> Result; {'nc:rpc-reply',_Attrs,Result} -> Result; OtherReply -> OtherReply end; {error, Reason} -> {error, Reason} end. to_simple_xml(Bin, Connection) when is_binary(Bin) -> {SimpleXml,_Rest} = xmerl_scan:string("", [{*continuation_fun, fun cont/3,* {Bin, false, Connection}}, {acc_fun,fun acc_simple_xml/3}, {space,normalize}, {hook_fun, fun hook_simple_xml/2}]), SimpleXml. cont(Continue, Exception, GlobalState) -> {OldTail, Found, Connection} = xmerl_scan:cont_state(GlobalState), if Found -> Continue(Exception,GlobalState); true -> case split_at_marker_or_last_whitespace(OldTail) of false -> *%% Need more data. {ok, Data} = netconf_transport:receive_data(Connection),* NewGlobalState = xmerl_scan:cont_state( {<>, false, Connection}, GlobalState), cont(Continue, Exception, NewGlobalState); {Marker, NewData, NewTail} -> NewGlobalState = xmerl_scan:cont_state({NewTail, Marker, Connection}, GlobalState), netconf_transport:adjust_window(Connection, length(NewData) + case Marker of true -> 6; _ -> 0 end), Continue(NewData, NewGlobalState) end end. %%%%%%%%%%%%% netconf_transport.erl %%%%%%%%%%%%% receive_data(Connection) -> receive_data(Connection, *infinity*). receive_data(#connection{transport = ssh}, Timeout) -> receive {ssh_cm, _Cm, {data, _Ch, _Type, Data}} -> {ok, Data}; {ssh_cm, _Cm, {Closed, _Ch}} when Closed == closed; Closed == eof -> exit(closed); {'DOWN',_,_,_,_} -> exit(normal) after *Timeout* -> {error, timeout} end; -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Oct 28 22:48:17 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 28 Oct 2013 14:48:17 -0700 (PDT) Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> How about adding this: term_compare(X,Y) -> '<' | '==' | '>'. Usage: case term_compare(X, Y) of ? '==' -> ...; ? ... end In that case, compare(X,Y) could be useful too.? Best, Thomas ? On Monday, October 28, 2013 8:07 PM, Bj?rn-Egil Dahlberg wrote: 2013/10/28 Robert Virding > >Great! But I do have some comments (of course): >> > > >Great! =) >? > >> >>- I would keep the function names from the dict module where possible. This to make it easier to convert. >> > > >I agree with your point. Ease of conversion would be great. But, why would dict be more suitable than gb_trees ? The current API is of personal preference ofc. > > >? > >> >>- I definitely agree about creating true term ordering comparison operators to complement =:= and =/=. But as I am more used to the prolog set (@==, @/=, @>, @>=, @< and @=<) I would much prefer to have them instead. They at least start with the same character. Anyway create the operators and define maps to use them, and then fix dict/orddict/gb_trees to use them as well so they are compatible. I could survive potential backwards compatibility problems with them to achieve consistency. >> > > >I'm thinking of writing another EEP. I did a test implementation of <:<, >:>, =:<, >:= this weekend to see how it would pan out. See,?https://github.com/psyeugenic/otp/commits/egil/total-order-relops for details. Seemed ok. The syntax can be changed to suite prolog heritage but the @... syntax freak me out to be honest =) > > >Also what should we do with =:= vs @== and =/= vs @/= in that case? Should we have two operators with the same meaning? >? > >> >>- I also definitely agree to keep the syntactic footprint to a minimum and introduce as little new syntax as possible. >> > > >Check. >? > >> >>- For map comprehensions I would NOT use <- as the generator operator as it tells me we are generating elements from a list. Binaries got a new operator and I think maps should as well, for example <:, or something else. >> > > >There are currently no generator implemented, and it might not be implemented either. Also, I think K := V <- Map works for the visual and it is definitely unique enough to be parsable. The difference of #{ K := V } <- List vs. K := V <- Map might be to subtle though. I think we might have to revisit this and give maps its own arrow. > > > > >Thank you! > > >//Bj?rn-Egil >? > >> >>Robert >> >> >> >> >> >>________________________________ >> >>From: "Bj?rn-Egil Dahlberg" >>> >>> >>> >>> Hi! >>> >>>Here you go, Maps! >>> >>>I've pushed a Maps branch to Erlang/OTPs repository at GitHub. >>> >>>To get the branch, >>> >>>? git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation >>> >>>or find it at https://github.com/erlang/otp/tree/egil/maps/eep-implementation >>> >>>I want to state the following so there is no room for uncertainty: >>>- This branch contains a development stage of the experimental Maps feature for Erlang. >>> >>>This means: >>>?- Do not use it in production since it is not stable, >>>?- Do not base any git branch on this branch since it will most likely be rebased, >>>?- and finally, we reserve the right to change any API or interfaces to Maps currently implemented. >>> >>>The implementation is based on EEP 43 - Maps, see http://github.com/erlang/eep/blob/master/eeps/eep-0043.md, for details. >>> >>>What is implemented? >>> >>>The maps module API and erlang guard BIFs as defined in the EEP are implemented. There are however some sematic mismatches with the EEP. I think those are where the definition contradict itself. For instance maps:is_key/1 compares with =:= as stated first in the definition but the later example uses lists:keymember which compares with ==. >>> >>>The syntax and all what that entails is implemented. The compiler will handle the map syntax and produce loadable beam-code. I believe this is what people want to test and is what I want people to test. Test the usability that is. >>> >>>I recommend people look at the EEP for information and also the testsuite located at erts/emulator/test/map_SUITE.erl for information on how to use Maps since no other documentation is available. >>> >>>Roughly, >>>? M0 = #{ key => Value1, "key" => Value2}, % for construction. >>>? M1 = M1#{? "key" := Value3, <<"key">> => Value4 }, % for updates >>>? #{ "key" := V } = M1. % for matching >>> >>>Where the operator '=>' (assoc operator) is used for extending and creating new Maps and the operator ':=' is used to update existing key/values. The ':=' operator is the only operator allowed in patterns. I'm guessing some confusion will arise from these two types of operators on where you can and/or should use them. >>> >>>Look at the tests and EEP for details and inspiration. >>> >>>A major difference from the EEP are variables in keys. Variables in keys are not allowed at all. This is because we want to reduce the scope for this first stage. Plenty to do besides that. >>> >>>Here are some additional disclaimers to make people sad. >>> >>>What is not implemented? >>> >>>- No variable keys. >>>- No single value access. >>>- No map comprehensions. >>>- No datastructure to handle large Maps. >>>- No MatchSpecs which uses the Maps syntax will work. >>> >>>Known issues >>> >>>- Dialyzer will not work with maps in the code, this include PLT building with erts and stdlib. >>>- HiPE, the native compiler, will not with maps code. >>>- EDoc will not work with maps. >>> >>>I'm sure there are other issues as well, it is a development branch after all. =) >>> >>>I would also like to point out that no optimizations are done either with respect to the generated code. This means that the instruction set may change. We know of several optimization we want to do before R17, especially for the match compiler so keep that in mind. >>> >>>We will continue stabilizing the Maps implementation as we move forward towards R17 and take appropriate action depending on the feedback you give us. >>> >>>I would like to continue with saying a few words about possible changes that we are thinking about. >>> >>>Variables in Keys >>> >>>This feature is actually furthest down on the work prio list. We want to stabilize the current features before moving forward and variable keys is the one most likely to be dropped if we get pressed for time. Meaning, it might not be implemented for R17 but instead implemented for R18. The plan right now is to keep it though. >>> >>>The External Format >>> >>>The current external format needs ordered keys as input for binary_to_term/1 and in distribution. >>> >>>This is of course an inconvinience when dealing with other language interfaces which has no idea of what the erlang term order is. I instead propose that the external format should handle unordered input of key-value pairs. The trade off is a more complicated decoding which will take longer. >>> >>>The distribution format should also be extended to be able cache keys. This is similar to the atom cache except we >>>cache the entire key array for maps. This has been the intention all along but it not mentioned in the EEP. >>> >>>Term order and sorting >>> >>>Finally the term order. This has been a sore point from the get go. >>> >>>Maps currently respects the Erlang term order for it's keys. >>> >>>The Erlang term order is what I call arithmetic term order. I propose that we extend Erlang with true term order where integer compares less then float, i.e. total term order. >>> >>>This would allowing newer ordered data structures, like maps, to be more useful. We don't have to take >>>special care for the odd cases like keys 1.0 and 1 inhabiting the same slot in the data structure. gb_trees and such structures could also be extended to use this as those structures has the same limitations. >>> >>>With this type ordering we could have maps with this type of keys, #{ 1 => "integer", 1.0 => "float" } without causing confusion. >>> >>>I've been told that ETS ordered sets tables used to have this behaviour. Distinguishing between floats and integers. This was supposedly before the open source era, way back when dinosaurs roamed the planet .. I'm not clear on the details on why this behaviour was removed. Probably because of inconsistencies. >>> >>>For maps to work with this I only need two things. First, a compare operation in the runtime that can distinguish between floats and integers, very easy. Secondly, a BIF that sort a list of terms with this new compare operation which will be used in the compiler. >>> >>>But for completness, the following operators should also be implemented: >>> >>>??? =:=???????? term exact equal to, already implemented >>>??? =/=???????? term not equal to, already implemented >>>??? =:>>??? >:=???????? term greater or equal than >>>??? <:>>??? >:>???????? term greater than >>> >>>So, true = 1 <:< 1.0. >>> >>>I don't know prolog but perhaps these sematics should mimic prolog to respect Erlangs heritage. I have no strong opinion on this. >>> >>>This syntax would mimic the already present =:= and =/= relational operators hower this syntax is another topic and should be a seperate EEP. >>> >>>Happy testing! >>> >>>Regards, >>>Bj?rn-Egil Dahlberg >>>Erlang/OTP >>> >>> >>>_______________________________________________ >>>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 aschultz@REDACTED Tue Oct 29 10:39:05 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Tue, 29 Oct 2013 10:39:05 +0100 (CET) Subject: [erlang-questions] ssl server multiple certificates In-Reply-To: References: <1229359405.703226.1382956170048.JavaMail.zimbra@tpip.net> Message-ID: <845209504.726709.1383039545585.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > Hi, > > I would like to have some feedback about the API modification. Ingela is the authority to ask, so just my 2 cent here.... > * Client side > No modification, SNI is used if the connection endpoint is a hostname, > not an ip address. Like that > * Server side > A new "sni_hosts" option can override ssl options on a per-hostname > basis: for exemple one can override the default certificate for the > vhost1.example.com hostname with the following ssl option: > {sni_hosts, [{"vhost1.example.com", [{certfile, "vhost1.pem"}, > {keyfile,"vhost1.key"}]}]} What about just 'hosts', the fact that is uses SNI does not really matter. > A new ssl:sni_hostname/1 function was added to get the wanted > hostname, for exemple in yaws one can imagine calling this function to > serve the website corresponding to the sni hostname. > > ok = ssl:ssl_accept(S), > SelectedHost = ssl:sni_hostname(S), Looking at the SSL API, it feels like a simple hostname/1 call would be more in line with for example peername and sockname. What would be the return if SNI wasn't negotiated, some kind of default, a special atom (e.g. undefined or unknown) or {error, unknown} ? > I recently updated the client side patch (the easier part), but need > some time to update the patch to work with the refactored ssl library. > > Feedbacks are welcome ! :) Andreas > > Regards, > > -- > Julien Barbot > > > 2013/10/28 Andreas Schultz > > > > Hi, > > > > ----- Original Message ----- > > > Hi! > > > > > > If I remember correctly someone worked on a contribution for this, but I > > > where in the middle of refactoring > > > things and I think it was not quite finished. > > > > Found it: > > http://erlang.org/pipermail/erlang-patches/2012-May/002787.html > > > > And copied the original author... would be nice to have this in R17 > > > > Andreas > > > > > Since then I have not had time > > > to follow up on it. I think it would > > > not be too hard to add support for it, but it is not our priority at the > > > moment, so please feel free to contribute. > > > And it is quite ok to send in a "pre-patch" to get feed back on API > > > choices > > > before you make the patch conform to all patch requirements. > > > > > > Regards Ingela Erlang/OTP team - Ericssson AB > > > > > > > > > 2013/10/25 Sergej Jurecko < sergej.jurecko@REDACTED > > > > > > > > > > hello, > > > > > > Is it possible to host multiple ssl certificates for different domains on > > > a > > > single IP and port? Like nginx is capable of doing. > > > > > > > > > Sergej > -- -- Dipl. Inform. Andreas Schultz From ingela.andin@REDACTED Tue Oct 29 14:51:09 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 29 Oct 2013 14:51:09 +0100 Subject: [erlang-questions] ssl server multiple certificates In-Reply-To: <845209504.726709.1383039545585.JavaMail.zimbra@tpip.net> References: <1229359405.703226.1382956170048.JavaMail.zimbra@tpip.net> <845209504.726709.1383039545585.JavaMail.zimbra@tpip.net> Message-ID: Hi! 2013/10/29 Andreas Schultz > Hi, > > ----- Original Message ----- > > Hi, > > > > I would like to have some feedback about the API modification. > > Ingela is the authority to ask, so just my 2 cent here.... > > > * Client side > > No modification, SNI is used if the connection endpoint is a hostname, > > not an ip address. > > Like that > > Feels good and should be ok as unknown extensions should be ignored. > > * Server side > > A new "sni_hosts" option can override ssl options on a per-hostname > > basis: for exemple one can override the default certificate for the > > vhost1.example.com hostname with the following ssl option: > > {sni_hosts, [{"vhost1.example.com", [{certfile, "vhost1.pem"}, > > {keyfile,"vhost1.key"}]}]} > > What about just 'hosts', the fact that is uses SNI does not really matter. > > I agree with Andreas on this point, SNI is an implementation detail. Maybe virtual_hosts would be more describing of what it is actually used for. > > A new ssl:sni_hostname/1 function was added to get the wanted > > hostname, for exemple in yaws one can imagine calling this function to > > serve the website corresponding to the sni hostname. > > > > ok = ssl:ssl_accept(S), > > SelectedHost = ssl:sni_hostname(S), > > Looking at the SSL API, it feels like a simple hostname/1 call would be > more in line with for example peername and sockname. > This would be a function defined only for the server? I like hostname! What would be the return if SNI wasn't negotiated, some kind of default, > a special atom (e.g. undefined or unknown) or {error, unknown} ? > > Maybe inet:gethostname() could be the default? So if the connection represents a virtual host you will get its name and otherwise you will get the actual hostname?! Regards Ingela Erlang/OTP team - Ericsson AB > I recently updated the client side patch (the easier part), but need > > some time to update the patch to work with the refactored ssl library. > > > > Feedbacks are welcome ! :) > > Andreas > > > > > Regards, > > > > -- > > Julien Barbot > > > > > > 2013/10/28 Andreas Schultz > > > > > > Hi, > > > > > > ----- Original Message ----- > > > > Hi! > > > > > > > > If I remember correctly someone worked on a contribution for this, > but I > > > > where in the middle of refactoring > > > > things and I think it was not quite finished. > > > > > > Found it: > > > http://erlang.org/pipermail/erlang-patches/2012-May/002787.html > > > > > > And copied the original author... would be nice to have this in R17 > > > > > > Andreas > > > > > > > Since then I have not had time > > > > to follow up on it. I think it would > > > > not be too hard to add support for it, but it is not our priority at > the > > > > moment, so please feel free to contribute. > > > > And it is quite ok to send in a "pre-patch" to get feed back on API > > > > choices > > > > before you make the patch conform to all patch requirements. > > > > > > > > Regards Ingela Erlang/OTP team - Ericssson AB > > > > > > > > > > > > 2013/10/25 Sergej Jurecko < sergej.jurecko@REDACTED > > > > > > > > > > > > > hello, > > > > > > > > Is it possible to host multiple ssl certificates for different > domains on > > > > a > > > > single IP and port? Like nginx is capable of doing. > > > > > > > > > > > > Sergej > > > > -- > -- > Dipl. Inform. > Andreas Schultz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Tue Oct 29 17:32:46 2013 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 29 Oct 2013 17:32:46 +0100 (CET) Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> "Not me against". But I think that term_compare/2 should return the term comparison operators <:<, =:=, >:> (or the @... alternatives) while compare/2 should return the old comparison operators as this is what they test. Robert ----- Original Message ----- > From: "Thomas Lindgren" > To: "Bj?rn-Egil Dahlberg" , "Robert Virding" > > Cc: "Erlang" > Sent: Monday, 28 October, 2013 10:48:17 PM > Subject: Re: [erlang-questions] Maps branch and disclaimers > How about adding this: > term_compare(X,Y) -> '<' | '==' | '>'. > Usage: > case term_compare(X, Y) of > '==' -> ...; > ... > end > In that case, compare(X,Y) could be useful too. > Best, > Thomas > On Monday, October 28, 2013 8:07 PM, Bj?rn-Egil Dahlberg > wrote: > > 2013/10/28 Robert Virding < robert.virding@REDACTED > > > > > Great! But I do have some comments (of course): > > > > > Great! =) > > > > - I would keep the function names from the dict module where possible. > > > This > > > to make it easier to convert. > > > > > I agree with your point. Ease of conversion would be great. But, why would > > dict be more suitable than gb_trees ? The current API is of personal > > preference ofc. > > > > - I definitely agree about creating true term ordering comparison > > > operators > > > to complement =:= and =/=. But as I am more used to the prolog set (@==, > > > @/=, @>, @>=, @< and @=<) I would much prefer to have them instead. They > > > at > > > least start with the same character. Anyway create the operators and > > > define > > > maps to use them, and then fix dict/orddict/gb_trees to use them as well > > > so > > > they are compatible. I could survive potential backwards compatibility > > > problems with them to achieve consistency. > > > > > I'm thinking of writing another EEP. I did a test implementation of <:<, > > >:>, > > =:<, >:= this weekend to see how it would pan out. See, > > https://github.com/psyeugenic/otp/commits/egil/total-order-relops for > > details. Seemed ok. The syntax can be changed to suite prolog heritage but > > the @... syntax freak me out to be honest =) > > > Also what should we do with =:= vs @== and =/= vs @/= in that case? Should > > we > > have two operators with the same meaning? > > > > - I also definitely agree to keep the syntactic footprint to a minimum > > > and > > > introduce as little new syntax as possible. > > > > > Check. > > > > - For map comprehensions I would NOT use <- as the generator operator as > > > it > > > tells me we are generating elements from a list. Binaries got a new > > > operator > > > and I think maps should as well, for example <:, or something else. > > > > > There are currently no generator implemented, and it might not be > > implemented > > either. Also, I think K := V <- Map works for the visual and it is > > definitely unique enough to be parsable. The difference of #{ K := V } <- > > List vs. K := V <- Map might be to subtle though. I think we might have to > > revisit this and give maps its own arrow. > > > Thank you! > > > //Bj?rn-Egil > > > > Robert > > > > > > > From: "Bj?rn-Egil Dahlberg" < egil@REDACTED > > > > > > > > > > > Hi! > > > > > > > > > > Here you go, Maps! > > > > > > > > > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > > > > > > > > > To get the branch, > > > > > > > > > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > > > > > > > > > or find it at > > > > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > > > > > > > > > I want to state the following so there is no room for uncertainty: > > > > > > > > > > - This branch contains a development stage of the experimental Maps > > > > feature > > > > for Erlang. > > > > > > > > > > This means: > > > > > > > > > > - Do not use it in production since it is not stable, > > > > > > > > > > - Do not base any git branch on this branch since it will most likely > > > > be > > > > rebased, > > > > > > > > > > - and finally, we reserve the right to change any API or interfaces to > > > > Maps > > > > currently implemented. > > > > > > > > > > The implementation is based on EEP 43 - Maps, see > > > > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md , for > > > > details. > > > > > > > > > > What is implemented? > > > > > > > > > > The maps module API and erlang guard BIFs as defined in the EEP are > > > > implemented. There are however some sematic mismatches with the EEP. I > > > > think > > > > those are where the definition contradict itself. For instance > > > > maps:is_key/1 > > > > compares with =:= as stated first in the definition but the later > > > > example > > > > uses lists:keymember which compares with ==. > > > > > > > > > > The syntax and all what that entails is implemented. The compiler will > > > > handle > > > > the map syntax and produce loadable beam-code. I believe this is what > > > > people > > > > want to test and is what I want people to test. Test the usability that > > > > is. > > > > > > > > > > I recommend people look at the EEP for information and also the > > > > testsuite > > > > located at erts/emulator/test/map_SUITE.erl for information on how to > > > > use > > > > Maps since no other documentation is available. > > > > > > > > > > Roughly, > > > > > > > > > > M0 = #{ key => Value1, "key" => Value2}, % for construction. > > > > > > > > > > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > > > > > > > > > > #{ "key" := V } = M1. % for matching > > > > > > > > > > Where the operator '=>' (assoc operator) is used for extending and > > > > creating > > > > new Maps and the operator ':=' is used to update existing key/values. > > > > The > > > > ':=' operator is the only operator allowed in patterns. I'm guessing > > > > some > > > > confusion will arise from these two types of operators on where you can > > > > and/or should use them. > > > > > > > > > > Look at the tests and EEP for details and inspiration. > > > > > > > > > > A major difference from the EEP are variables in keys. Variables in > > > > keys > > > > are > > > > not allowed at all. This is because we want to reduce the scope for > > > > this > > > > first stage. Plenty to do besides that. > > > > > > > > > > Here are some additional disclaimers to make people sad. > > > > > > > > > > What is not implemented? > > > > > > > > > > - No variable keys. > > > > > > > > > > - No single value access. > > > > > > > > > > - No map comprehensions. > > > > > > > > > > - No datastructure to handle large Maps. > > > > > > > > > > - No MatchSpecs which uses the Maps syntax will work. > > > > > > > > > > Known issues > > > > > > > > > > - Dialyzer will not work with maps in the code, this include PLT > > > > building > > > > with erts and stdlib. > > > > > > > > > > - HiPE, the native compiler, will not with maps code. > > > > > > > > > > - EDoc will not work with maps. > > > > > > > > > > I'm sure there are other issues as well, it is a development branch > > > > after > > > > all. =) > > > > > > > > > > I would also like to point out that no optimizations are done either > > > > with > > > > respect to the generated code. This means that the instruction set may > > > > change. We know of several optimization we want to do before R17, > > > > especially > > > > for the match compiler so keep that in mind. > > > > > > > > > > We will continue stabilizing the Maps implementation as we move forward > > > > towards R17 and take appropriate action depending on the feedback you > > > > give > > > > us. > > > > > > > > > > I would like to continue with saying a few words about possible changes > > > > that > > > > we are thinking about. > > > > > > > > > > Variables in Keys > > > > > > > > > > This feature is actually furthest down on the work prio list. We want > > > > to > > > > stabilize the current features before moving forward and variable keys > > > > is > > > > the one most likely to be dropped if we get pressed for time. Meaning, > > > > it > > > > might not be implemented for R17 but instead implemented for R18. The > > > > plan > > > > right now is to keep it though. > > > > > > > > > > The External Format > > > > > > > > > > The current external format needs ordered keys as input for > > > > binary_to_term/1 > > > > and in distribution. > > > > > > > > > > This is of course an inconvinience when dealing with other language > > > > interfaces which has no idea of what the erlang term order is. I > > > > instead > > > > propose that the external format should handle unordered input of > > > > key-value > > > > pairs. The trade off is a more complicated decoding which will take > > > > longer. > > > > > > > > > > The distribution format should also be extended to be able cache keys. > > > > This > > > > is similar to the atom cache except we > > > > > > > > > > cache the entire key array for maps. This has been the intention all > > > > along > > > > but it not mentioned in the EEP. > > > > > > > > > > Term order and sorting > > > > > > > > > > Finally the term order. This has been a sore point from the get go. > > > > > > > > > > Maps currently respects the Erlang term order for it's keys. > > > > > > > > > > The Erlang term order is what I call arithmetic term order. I propose > > > > that > > > > we > > > > extend Erlang with true term order where integer compares less then > > > > float, > > > > i.e. total term order. > > > > > > > > > > This would allowing newer ordered data structures, like maps, to be > > > > more > > > > useful. We don't have to take > > > > > > > > > > special care for the odd cases like keys 1.0 and 1 inhabiting the same > > > > slot > > > > in the data structure. gb_trees and such structures could also be > > > > extended > > > > to use this as those structures has the same limitations. > > > > > > > > > > With this type ordering we could have maps with this type of keys, #{ 1 > > > > => > > > > "integer", 1.0 => "float" } without causing confusion. > > > > > > > > > > I've been told that ETS ordered sets tables used to have this > > > > behaviour. > > > > Distinguishing between floats and integers. This was supposedly before > > > > the > > > > open source era, way back when dinosaurs roamed the planet .. I'm not > > > > clear > > > > on the details on why this behaviour was removed. Probably because of > > > > inconsistencies. > > > > > > > > > > For maps to work with this I only need two things. First, a compare > > > > operation > > > > in the runtime that can distinguish between floats and integers, very > > > > easy. > > > > Secondly, a BIF that sort a list of terms with this new compare > > > > operation > > > > which will be used in the compiler. > > > > > > > > > > But for completness, the following operators should also be > > > > implemented: > > > > > > > > > > =:= term exact equal to, already implemented > > > > > > > > > > =/= term not equal to, already implemented > > > > > > > > > > =:< term less or equal than > > > > > > > > > > >:= term greater or equal than > > > > > > > > > > <:< term less than > > > > > > > > > > >:> term greater than > > > > > > > > > > So, true = 1 <:< 1.0. > > > > > > > > > > I don't know prolog but perhaps these sematics should mimic prolog to > > > > respect > > > > Erlangs heritage. I have no strong opinion on this. > > > > > > > > > > This syntax would mimic the already present =:= and =/= relational > > > > operators > > > > hower this syntax is another topic and should be a seperate EEP. > > > > > > > > > > Happy testing! > > > > > > > > > > Regards, > > > > > > > > > > Bj?rn-Egil Dahlberg > > > > > > > > > > Erlang/OTP > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 jose.valim@REDACTED Tue Oct 29 17:39:16 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 29 Oct 2013 17:39:16 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: > "Not me against". > > But I think that term_compare/2 should return the term comparison > operators <:<, =:=, >:> (or the @... alternatives) while compare/2 should > return the old comparison operators as this is what they test. > Another idea is to make them return -1, 0 and 1. Then you can use the output of both term_compare/2 and compare/2 (or any other comparison function) without checking for specific operators. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 29 18:05:34 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 29 Oct 2013 18:05:34 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: I would rather have lt/eq/gt atoms than operator names or integers. Otherwise I really fancy red bikes. -- Anthony Ramine Le 29 oct. 2013 ? 17:39, Jos? Valim a ?crit : > Another idea is to make them return -1, 0 and 1. Then you can use the output of both term_compare/2 and compare/2 (or any other comparison function) without checking for specific operators. > From overminddl1@REDACTED Tue Oct 29 19:15:38 2013 From: overminddl1@REDACTED (OvermindDL1) Date: Tue, 29 Oct 2013 12:15:38 -0600 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: +1 for -1, 0, and 1, math simplifies then in cases On Oct 29, 2013 10:39 AM, "Jos? Valim" wrote: > > "Not me against". >> >> But I think that term_compare/2 should return the term comparison >> operators <:<, =:=, >:> (or the @... alternatives) while compare/2 should >> return the old comparison operators as this is what they test. >> > > Another idea is to make them return -1, 0 and 1. Then you can use the > output of both term_compare/2 and compare/2 (or any other comparison > function) without checking for specific operators. > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > _______________________________________________ > 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 Tue Oct 29 19:18:42 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 29 Oct 2013 19:18:42 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 wrote: > +1 for -1, 0, and 1, math simplifies then in cases No -1000 for this bad insane idea. Comparison is an algebraic datatype with three outcomes: lt, eq or gt. You DON'T use an integer domain to represent that. Why not -1337, 0 and +230439204830948320498 instead? They are equally good I guess! We don't need to diverge from Standard ML. We need to converge! -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Tue Oct 29 19:23:36 2013 From: bob@REDACTED (Bob Ippolito) Date: Tue, 29 Oct 2013 11:23:36 -0700 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: +1 to that :) On Tue, Oct 29, 2013 at 11:18 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 wrote: > >> +1 for -1, 0, and 1, math simplifies then in cases > > > No -1000 for this bad insane idea. Comparison is an algebraic datatype > with three outcomes: lt, eq or gt. You DON'T use an integer domain to > represent that. Why not -1337, 0 and +230439204830948320498 instead? They > are equally good I guess! > > We don't need to diverge from Standard ML. We need to converge! > > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Tue Oct 29 20:00:40 2013 From: ivan@REDACTED (Ivan uemlianin) Date: Tue, 29 Oct 2013 20:00:40 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: <63EFF6D8-FD51-4527-9F41-8DB92A8A5989@llaisdy.com> gt -- festina lente On 29 Oct 2013, at 19:18, Jesper Louis Andersen wrote: > > On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 wrote: >> +1 for -1, 0, and 1, math simplifies then in cases > > No -1000 for this bad insane idea. Comparison is an algebraic datatype with three outcomes: lt, eq or gt. You DON'T use an integer domain to represent that. Why not -1337, 0 and +230439204830948320498 instead? They are equally good I guess! > > We don't need to diverge from Standard ML. We need to converge! > > > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Tue Oct 29 20:23:11 2013 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 29 Oct 2013 20:23:11 +0100 (CET) Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> You couldn't have values like that, they're not primes. Robert ----- Original Message ----- > From: "Jesper Louis Andersen" > On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 < overminddl1@REDACTED > wrote: > > +1 for -1, 0, and 1, math simplifies then in cases > > No -1000 for this bad insane idea. Comparison is an algebraic datatype with > three outcomes: lt, eq or gt. You DON'T use an integer domain to represent > that. Why not -1337, 0 and +230439204830948320498 instead? They are equally > good I guess! > We don't need to diverge from Standard ML. We need to converge! > -- > J. > _______________________________________________ > 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 Tue Oct 29 20:41:45 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 29 Oct 2013 20:41:45 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> Message-ID: Ok, then lets use, 12572247014351 which happens to be a prime. No, there are good reasons for not using the integer domain in this way: first of all, the type of comparisons will be type x datatype order = EQ | LT | GT val compare : x * x -> order rather than val compare : x * x -> int Do note, that if we had something like view-types, we can easily convert from order to the integer domain: view(eq) -> 0; view(lt) -> -1; view(gt) -> 1. This function is exhaustive in the input type. Whereas the opposite definition will fail for view(1337), for instance. I do know Erlang is a unityped language, but whenever there is a possibility of picking an interface from a polytyped language, they are much to be preferred. Do note that this is in order with Standard ML and Haskell, whereas Ocaml chose the int-path. But I still think comparison should be case-analysed. Another problem with an integer is that compare(X, Y) * compare(Y, Z) is a valid expression, but it has no meaning whatsoever. On Tue, Oct 29, 2013 at 8:23 PM, Robert Virding < robert.virding@REDACTED> wrote: > You couldn't have values like that, they're not primes. > > Robert > > ------------------------------ > > *From: *"Jesper Louis Andersen" > > > On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 wrote: > >> +1 for -1, 0, and 1, math simplifies then in cases > > > No -1000 for this bad insane idea. Comparison is an algebraic datatype > with three outcomes: lt, eq or gt. You DON'T use an integer domain to > represent that. Why not -1337, 0 and +230439204830948320498 instead? They > are equally good I guess! > > We don't need to diverge from Standard ML. We need to converge! > > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Tue Oct 29 20:51:17 2013 From: colanderman@REDACTED (Chris King) Date: Tue, 29 Oct 2013 15:51:17 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Tue, Oct 29, 2013 at 3:41 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > view(eq) -> 0; > view(lt) -> -1; > view(gt) -> 1. > > This function is exhaustive in the input type. > No it's not. Unless you define the input type as :- type order() :: eq | lt | gt. Well, you can do the same thing with integers in Erlang: :- type order() :: -1 | 0 | 1. > Another problem with an integer is that > > compare(X, Y) * compare(Y, Z) is a valid expression, but it has no meaning > whatsoever. > And with atoms, list_to_atom(lists:append(atom_to_list(X), atom_to_list(Y)) is equally meaningless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Tue Oct 29 21:00:23 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 29 Oct 2013 16:00:23 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> Message-ID: <20131029200022.GH5671@ferdair.local> The advantage I see with returning operator atoms directly is being able to do fancy crap like erlang:apply(erlang, operator(), [A,B]) or whatever, or maybe passing them as funs, which otherwise would need to be manually converted using lt / eq / gt, or 1 / 0 / -1, while still being able to match on them (although it would require more syntax by quoting atoms). On 10/29, Anthony Ramine wrote: > I would rather have lt/eq/gt atoms than operator names or integers. > > Otherwise I really fancy red bikes. > > -- > Anthony Ramine > > Le 29 oct. 2013 ? 17:39, Jos? Valim a ?crit : > > > Another idea is to make them return -1, 0 and 1. Then you can use the output of both term_compare/2 and compare/2 (or any other comparison function) without checking for specific operators. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From chuck.irvine@REDACTED Tue Oct 29 20:02:59 2013 From: chuck.irvine@REDACTED (Charles Irvine) Date: Tue, 29 Oct 2013 14:02:59 -0500 Subject: [erlang-questions] Workflow process model Message-ID: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> I plan to write a BPM (Workflow) engine in Erlang. I?m struggling with what the process model ought to be. Suggestions would be greatly appreciated. Here?s the general structure of the system: Users construct a process model for an purposeful activity. Let?s say the activity is to fix a software defect. The process model is a set of tasks sequenced to achieve the goal of the process. The process model for fixing a defect would be: OpenDefect -> WriteCodeToFixDefect -> DeployFixCodeToTestEnv -> TestFix -> DeployCodeToProd A single instance of this flow of task completion I call a workflow instance. There may be a large number of such instances in progress concurrently. The state of a workflow instance is a set of outstanding tasks ready to be performed and what I call a workflow context. A workflow context is a set of informational artifacts accumulated as the workflow progresses. For example the state of defect resolution workflow instance might be an instance of the task WriteCodeToFixDefect and the context would be a defect description. I?ve considered making each such workflow instance a process but I hesitate to do this since a process may have a relatively long lifetime and there might be a long duration between significant events. For example, a defect might not get fixed for weeks or months and a long time could elapse between the time the defect is reported and the time that someone starts working on it. A little nudge or two from folks more skilled than me at this would be much appreciated. From siraaj@REDACTED Tue Oct 29 21:15:15 2013 From: siraaj@REDACTED (Siraaj Khandkar) Date: Tue, 29 Oct 2013 16:15:15 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> Message-ID: <52701753.4030807@khandkar.net> On 10/29/2013 03:51 PM, Chris King wrote: > > On Tue, Oct 29, 2013 at 3:41 PM, Jesper Louis Andersen > > wrote: > > > view(eq) -> 0; > view(lt) -> -1; > view(gt) -> 1. > > This function is exhaustive in the input type. > > > No it's not. Unless you define the input type as :- type order() :: eq > | lt | gt. Well, you can do the same thing with integers in Erlang: :- > type order() :: -1 | 0 | 1. Sure. Let's entertain this thought for a sec: the lt|eq|gt are in the domain of atoms and are impractical to make _truly_ exhaustive. However, remember this - atoms, by their very purpose, carry symbolic meaning, whereas integers do not. If you see 0 or 1 or -1 outside of context - they mean next to 0 to you (pun very much intended), whereas if you see 'lt', 'gt' or 'eq' - you have a pretty good clue about where they could have come from. > > Another problem with an integer is that > > compare(X, Y) * compare(Y, Z) is a valid expression, but it has no > meaning whatsoever. > > > And with atoms, list_to_atom(lists:append(atom_to_list(X), > atom_to_list(Y)) is equally meaningless. > > From colanderman@REDACTED Tue Oct 29 21:17:04 2013 From: colanderman@REDACTED (Chris King) Date: Tue, 29 Oct 2013 16:17:04 -0400 Subject: [erlang-questions] Workflow process model In-Reply-To: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> References: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> Message-ID: You probably want to use a database (such as mnesia). Processes won't survive a system crash. Use processes for more transient state machines (such as client sessions). On Tue, Oct 29, 2013 at 3:02 PM, Charles Irvine wrote: > I plan to write a BPM (Workflow) engine in Erlang. I?m struggling with > what the process model ought to be. Suggestions would be greatly > appreciated. Here?s the general structure of the system: > > Users construct a process model for an purposeful activity. Let?s say the > activity is to fix a software defect. The process model is a set of tasks > sequenced to achieve the goal of the process. The process model for fixing > a defect would be: > > OpenDefect -> WriteCodeToFixDefect -> DeployFixCodeToTestEnv -> TestFix -> > DeployCodeToProd > > A single instance of this flow of task completion I call a workflow > instance. There may be a large number of such instances in progress > concurrently. The state of a workflow instance is a set of outstanding > tasks ready to be performed and what I call a workflow context. A workflow > context is a set of informational artifacts accumulated as the workflow > progresses. > > For example the state of defect resolution workflow instance might be an > instance of the task WriteCodeToFixDefect and the context would be a defect > description. > > I?ve considered making each such workflow instance a process but I > hesitate to do this since a process may have a relatively long lifetime and > there might be a long duration between significant events. For example, a > defect might not get fixed for weeks or months and a long time could elapse > between the time the defect is reported and the time that someone starts > working on it. > > A little nudge or two from folks more skilled than me at this would be > much appreciated. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Tue Oct 29 21:20:27 2013 From: colanderman@REDACTED (Chris King) Date: Tue, 29 Oct 2013 16:20:27 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <52701753.4030807@khandkar.net> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> <52701753.4030807@khandkar.net> Message-ID: On Tue, Oct 29, 2013 at 4:15 PM, Siraaj Khandkar wrote: > > Sure. Let's entertain this thought for a sec: the lt|eq|gt are in the > domain of atoms and are impractical to make _truly_ exhaustive. However, > remember this - atoms, by their very purpose, carry symbolic meaning, > whereas integers do not. If you see 0 or 1 or -1 outside of context - they > mean next to 0 to you (pun very much intended), whereas if you see 'lt', > 'gt' or 'eq' - you have a pretty good clue about where they could have come > from. Sure. I'm not taking a side; just pointing out invalid reasoning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Oct 29 21:33:22 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 29 Oct 2013 21:33:22 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Tue, Oct 29, 2013 at 8:51 PM, Chris King wrote: > No it's not. Unless you define the input type as :- type order() :: eq | > lt | gt. Well, you can do the same thing with integers in Erlang: :- type > order() :: -1 | 0 | 1. Depending on the type system, this is either possible or it is not. A type system based on success types can allow it, but then you have the problem that it isn't a traditional type system. If you want a traditional static type system, then I'd bet that it won't be trivial to handle -1 | 0 | 1 as a subtype of the integers. You need either dependent types or refinement types. And that will be a beast to tackle. I really dislike not using atoms for this. Intuitively and because of the inherent type complexity (yes, I have a bias here). -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Oct 29 21:52:39 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 29 Oct 2013 21:52:39 +0100 Subject: [erlang-questions] Workflow process model In-Reply-To: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> References: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> Message-ID: On Tue, Oct 29, 2013 at 8:02 PM, Charles Irvine wrote: > A little nudge or two from folks more skilled than me at this would be > much appreciated. Ok, here is my take on it: Each workflow instance is a process. This process replays an (immutable) event log from stable storage. Each event in the log is stamped with a time stamp and the process replays the events as if they happened at that point in time. New events are injected to the process with a time stamp. So a process is always "lagging behind" by something, be it weeks or microseconds. When processing new events, these are written to stable storage. Thus ensuring you can reawaken the process later and retrace its steps should it be possible. Note that BPM system upgrades needs to be in the event log too, so you can switch code versions. Write the SHA256 checksum of event log and the internal process state to mnesia so you can avoid retracing steps if the workflow becomes too long. Processes have lifetime. When they are active, they are registered in a registry, like gproc. When you know they are going to be inactive for a long period, you can terminate the process, but keep a notion of the workflow instance on stable storage, so you can restart it if necessary. A message for an inactive workflow awakens it. Use timers to terminate inactive workflows. Or don't. You can probably have a million workflows in a couple of gigabytes of memory. The advantage of this model compared to a database-centric one is that the process can act "on its own". That is, rather than operating on the data, the *process* is the data and it can communicate and spew out events itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Tue Oct 29 22:33:57 2013 From: colanderman@REDACTED (Chris King) Date: Tue, 29 Oct 2013 17:33:57 -0400 Subject: [erlang-questions] Workflow process model In-Reply-To: References: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> Message-ID: On Tue, Oct 29, 2013 at 4:28 PM, Charles Irvine wrote: > I do realize that workflow state will need to be stored to a database. > Usually you want to choose between storing state in a process or in a database. The only time you'd want to do both is for caching (in which case you would either have many short-lived processes or a few long-lived processes). > I don't envision much in the way of client sessions. > If you have clients connecting over TCP or something you definitely want per-client processes (even if they only process one request and then end the session). Doing this will simplify your code flow dramatically. > The thing that will drive the system are task completions. Task completion > adds information to the workflow context and generates new tasks to be > completed. > This is the biggest decision to make IMO with respect to process model. Depending on the complexity of this process, you could either: 1) perform a mnesia transaction in the client process 2) start a process to perform the mnesia transaction (and maybe other actions) 3) call a long-lived process (a gen_server) to perform the mnesia transaction (and maybe other actions that must be synchronized) -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Tue Oct 29 22:41:02 2013 From: colanderman@REDACTED (Chris King) Date: Tue, 29 Oct 2013 17:41:02 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Tue, Oct 29, 2013 at 4:33 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Tue, Oct 29, 2013 at 8:51 PM, Chris King wrote: > >> No it's not. Unless you define the input type as :- type order() :: eq | >> lt | gt. Well, you can do the same thing with integers in Erlang: :- type >> order() :: -1 | 0 | 1. > > > Depending on the type system, this is either possible or it is not. A type > system based on success types can allow it, but then you have the problem > that it isn't a traditional type system. > I know. I used OCaml for years before coming to Erlang. A smattering of Coq too. > If you want a traditional static type system, then I'd bet that it won't > be trivial to handle -1 | 0 | 1 as a subtype of the integers. > OCaml manages it for atoms with polymorphic variant types. Checking integer subtypes in the presence of arithmetic is more difficult, yes, but that's not an issue here (both because (a) we're not doing arithmetic and (b) Dialyzer's type engine is complete but not sound). > I really dislike not using atoms for this. Intuitively and because of the > inherent type complexity (yes, I have a bias here). > Having migrated from the ML camp after living in it for a decade, I think the perceived complexity is an artifact of the HM type system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.irvine@REDACTED Tue Oct 29 21:28:00 2013 From: chuck.irvine@REDACTED (Charles Irvine) Date: Tue, 29 Oct 2013 15:28:00 -0500 Subject: [erlang-questions] Workflow process model In-Reply-To: References: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> Message-ID: I do realize that workflow state will need to be stored to a database. I don't envision much in the way of client sessions. The thing that will drive the system are task completions. Task completion adds information to the workflow context and generates new tasks to be completed. I am new to Erlang and I read that the challenge is to create the correct process model. So, I am trying to figure that out. Thanks! Sent from my iPad > On Oct 29, 2013, at 3:17 PM, Chris King wrote: > > You probably want to use a database (such as mnesia). Processes won't survive a system crash. Use processes for more transient state machines (such as client sessions). > > >> On Tue, Oct 29, 2013 at 3:02 PM, Charles Irvine wrote: >> I plan to write a BPM (Workflow) engine in Erlang. I?m struggling with what the process model ought to be. Suggestions would be greatly appreciated. Here?s the general structure of the system: >> >> Users construct a process model for an purposeful activity. Let?s say the activity is to fix a software defect. The process model is a set of tasks sequenced to achieve the goal of the process. The process model for fixing a defect would be: >> >> OpenDefect -> WriteCodeToFixDefect -> DeployFixCodeToTestEnv -> TestFix -> DeployCodeToProd >> >> A single instance of this flow of task completion I call a workflow instance. There may be a large number of such instances in progress concurrently. The state of a workflow instance is a set of outstanding tasks ready to be performed and what I call a workflow context. A workflow context is a set of informational artifacts accumulated as the workflow progresses. >> >> For example the state of defect resolution workflow instance might be an instance of the task WriteCodeToFixDefect and the context would be a defect description. >> >> I?ve considered making each such workflow instance a process but I hesitate to do this since a process may have a relatively long lifetime and there might be a long duration between significant events. For example, a defect might not get fixed for weeks or months and a long time could elapse between the time the defect is reported and the time that someone starts working on it. >> >> A little nudge or two from folks more skilled than me at this would be much appreciated. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From z_axis@REDACTED Wed Oct 30 03:10:31 2013 From: z_axis@REDACTED (z_axis) Date: Wed, 30 Oct 2013 10:10:31 +0800 Subject: [erlang-questions] R16B02 error on FreeBSD Message-ID: I am frustrated by R16B02 : "beam/erl_bif_re.c:984: error: 'PCRE_EXTRA_LOOP_LIMIT' undeclared (first use in this function)\n beam/erl_bif_re.c:986: error: 'pcre_extra' has no member named 'loop_limit' ..." when compiling on FreeBSD Sincerely! From desired.mta@REDACTED Wed Oct 30 08:27:55 2013 From: desired.mta@REDACTED (=?UTF-8?B?TW90aWVqdXMgSmFrxaF0eXM=?=) Date: Wed, 30 Oct 2013 08:27:55 +0100 Subject: [erlang-questions] Workflow process model In-Reply-To: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> References: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> Message-ID: <5270B4FB.8010208@gmail.com> 2013.10.29 20:02, Charles Irvine ra??: > I?ve considered making each such workflow instance a process but I > hesitate to do this since a process may have a relatively long > lifetime and there might be a long duration between significant > events. For example, a defect might not get fixed for weeks or months > and a long time could elapse between the time the defect is reported > and the time that someone starts working on it. > > A little nudge or two from folks more skilled than me at this would > be much appreciated. I (together with a few people in this mailing list) created a tool to manage number portability database (when you migrate your phone number from one operator to another, some entity has to mediate it) on national scale. A single process is responsible for a single transaction, which includes a range of numbers. Transactions can last from 1 day to years. A process is a state machine which just sends messages to operators according to some rules. One transaction is an erlang process, which, if does not receive a message for 60 minutes, hibernates. When you hibernate, you do not worry about the number of processes. We also had distribution, so there was no practical ceiling. For recovery and audit purposes you can log every incoming/outgoing message. That will let you reply all transactions and return to the state before crash (we did it wrong way, but later realized that this should have been done instead). So in short, stick to the process model and, if you are worried about number of them, hibernate. I just tried running 1M hibernated processes on a 64bit laptop. Takes 866M residential memory. Of course, yours will take more depending on size of your state. But still it's cheap. Motiejus From eriksoe@REDACTED Wed Oct 30 08:55:00 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Wed, 30 Oct 2013 08:55:00 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1382996897.67699.YahooMailNeo@web140106.mail.bf1.yahoo.com> <1416949404.374617.1383064366734.JavaMail.zimbra@erlang-solutions.com> <1748754202.377556.1383074591888.JavaMail.zimbra@erlang-solutions.com> Message-ID: Den 29/10/2013 20.42 skrev "Jesper Louis Andersen" < jesper.louis.andersen@REDACTED>: > > Ok, then lets use, 12572247014351 which happens to be a prime. > > No, there are good reasons for not using the integer domain in this way: > > first of all, the type of comparisons will be > > type x > datatype order = EQ | LT | GT > > val compare : x * x -> order > > rather than > > val compare : x * x -> int > > Do note, that if we had something like view-types, we can easily convert from order to the integer domain: > > view(eq) -> 0; > view(lt) -> -1; > view(gt) -> 1. The one argument I see against atoms is that eq < gt < lt - and that is easily fixable with a view function. > This function is exhaustive in the input type. Whereas the opposite definition will fail for view(1337), for instance. I do know Erlang is a unityped language, but whenever there is a possibility of picking an interface from a polytyped language, they are much to be preferred. > > Do note that this is in order with Standard ML and Haskell, whereas Ocaml chose the int-path. But I still think comparison should be case-analysed. > > Another problem with an integer is that > > compare(X, Y) * compare(Y, Z) is a valid expression, but it has no meaning whatsoever. Bad example, I'm afraid: the result is 1 whenever the numbers are in order, either x y> z; and -1 whenever y is a strict extreme. (Not that it changes anything much.) > On Tue, Oct 29, 2013 at 8:23 PM, Robert Virding < robert.virding@REDACTED> wrote: >> >> You couldn't have values like that, they're not primes. >> >> Robert >> >> ________________________________ >>> >>> From: "Jesper Louis Andersen" >>> >>> >>> On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 wrote: >>>> >>>> +1 for -1, 0, and 1, math simplifies then in cases >>> >>> >>> No -1000 for this bad insane idea. Comparison is an algebraic datatype with three outcomes: lt, eq or gt. You DON'T use an integer domain to represent that. Why not -1337, 0 and +230439204830948320498 instead? They are equally good I guess! >>> >>> We don't need to diverge from Standard ML. We need to converge! >>> >>> >>> >>> -- >>> J. >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Wed Oct 30 10:11:46 2013 From: garazdawi@REDACTED (Lukas Larsson) Date: Wed, 30 Oct 2013 10:11:46 +0100 Subject: [erlang-questions] R16B02 error on FreeBSD In-Reply-To: References: Message-ID: Hello, You forgot to mention which gcc and FreeBSD version you are using. Lukas On Wed, Oct 30, 2013 at 3:10 AM, z_axis wrote: > I am frustrated by R16B02 : "beam/erl_bif_re.c:984: error: > 'PCRE_EXTRA_LOOP_LIMIT' undeclared (first use in this function)\n > beam/erl_bif_re.c:986: error: 'pcre_extra' has no member named > 'loop_limit' ..." when compiling on FreeBSD > > Sincerely! > > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Wed Oct 30 10:55:59 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 30 Oct 2013 10:55:59 +0100 (CET) Subject: [erlang-questions] ssl server multiple certificates In-Reply-To: References: <1229359405.703226.1382956170048.JavaMail.zimbra@tpip.net> <845209504.726709.1383039545585.JavaMail.zimbra@tpip.net> Message-ID: <665059917.757637.1383126959525.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > Hi! > > 2013/10/29 Andreas Schultz > > > Hi, > > > > ----- Original Message ----- > > > Hi, > > > > > > I would like to have some feedback about the API modification. > > > > Ingela is the authority to ask, so just my 2 cent here.... > > > > > * Client side > > > No modification, SNI is used if the connection endpoint is a hostname, > > > not an ip address. > > > > Like that > > > > > Feels good and should be ok as unknown extensions should be ignored. After thinking about it more, it believe that we still need an option to set the SNI hostname explicitly. I see two use cases, first contacting a server know only be IP address but still wanting virtual host support, and the other is upgrading an already established TCP connection to TLS with virtual server selection within TLS. So maybe am {virtual_host, string()} option? Andreas > > > > > > * Server side > > > A new "sni_hosts" option can override ssl options on a per-hostname > > > basis: for exemple one can override the default certificate for the > > > vhost1.example.com hostname with the following ssl option: > > > {sni_hosts, [{"vhost1.example.com", [{certfile, "vhost1.pem"}, > > > {keyfile,"vhost1.key"}]}]} > > > > What about just 'hosts', the fact that is uses SNI does not really matter. > > > > > I agree with Andreas on this point, SNI is an implementation detail. > Maybe virtual_hosts would be more describing of what it is actually used > for. > > > > > > A new ssl:sni_hostname/1 function was added to get the wanted > > > hostname, for exemple in yaws one can imagine calling this function to > > > serve the website corresponding to the sni hostname. > > > > > > ok = ssl:ssl_accept(S), > > > SelectedHost = ssl:sni_hostname(S), > > > > Looking at the SSL API, it feels like a simple hostname/1 call would be > > more in line with for example peername and sockname. > > > > This would be a function defined only for the server? I like hostname! > > > What would be the return if SNI wasn't negotiated, some kind of default, > > a special atom (e.g. undefined or unknown) or {error, unknown} ? > > > > > Maybe inet:gethostname() could be the default? So if the connection > represents a virtual host you will get its name and otherwise you will > get the actual hostname?! > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > I recently updated the client side patch (the easier part), but need > > > some time to update the patch to work with the refactored ssl library. > > > > > > Feedbacks are welcome ! :) > > > > Andreas > > > > > > > > Regards, > > > > > > -- > > > Julien Barbot > > > > > > > > > 2013/10/28 Andreas Schultz > > > > > > > > Hi, > > > > > > > > ----- Original Message ----- > > > > > Hi! > > > > > > > > > > If I remember correctly someone worked on a contribution for this, > > but I > > > > > where in the middle of refactoring > > > > > things and I think it was not quite finished. > > > > > > > > Found it: > > > > http://erlang.org/pipermail/erlang-patches/2012-May/002787.html > > > > > > > > And copied the original author... would be nice to have this in R17 > > > > > > > > Andreas > > > > > > > > > Since then I have not had time > > > > > to follow up on it. I think it would > > > > > not be too hard to add support for it, but it is not our priority at > > the > > > > > moment, so please feel free to contribute. > > > > > And it is quite ok to send in a "pre-patch" to get feed back on API > > > > > choices > > > > > before you make the patch conform to all patch requirements. > > > > > > > > > > Regards Ingela Erlang/OTP team - Ericssson AB > > > > > > > > > > > > > > > 2013/10/25 Sergej Jurecko < sergej.jurecko@REDACTED > > > > > > > > > > > > > > > > hello, > > > > > > > > > > Is it possible to host multiple ssl certificates for different > > domains on > > > > > a > > > > > single IP and port? Like nginx is capable of doing. > > > > > > > > > > > > > > > Sergej > > > > > > > -- > > -- > > Dipl. Inform. > > Andreas Schultz > > > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From robert.virding@REDACTED Wed Oct 30 13:40:44 2013 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 30 Oct 2013 13:40:44 +0100 (CET) Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> Message-ID: <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> Skipping compare for a moment I have more comments/suggestions: - generate 'badarg' errors instead of 'badmap' which would be consistent with other type errors. - I need functions: first(Map) -> {Key,Value} | error. last(Map) -> {Key,Value} | error. next(Key, Map) -> {Key1,Value} | error. prev(Key, Map) -> {Key1,Value} | error. for stepping through maps. Have them return both key and value in one go as it saves an explicit fetch and the extra cost is minimal. - I prefer the dict API over gb_trees as you don't have the two cases whether it is there or not. - Use term ordering internally as IMAO this is better. Robert ----- Original Message ----- > From: "Bj?rn-Egil Dahlberg" > To: "Robert Virding" > Cc: "Bj?rn-Egil Dahlberg" , "Erlang" > > Sent: Monday, 28 October, 2013 8:06:55 PM > Subject: Re: [erlang-questions] Maps branch and disclaimers > 2013/10/28 Robert Virding < robert.virding@REDACTED > > > Great! But I do have some comments (of course): > > Great! =) > > - I would keep the function names from the dict module where possible. This > > to make it easier to convert. > > I agree with your point. Ease of conversion would be great. But, why would > dict be more suitable than gb_trees ? The current API is of personal > preference ofc. > > - I definitely agree about creating true term ordering comparison operators > > to complement =:= and =/=. But as I am more used to the prolog set (@==, > > @/=, @>, @>=, @< and @=<) I would much prefer to have them instead. They at > > least start with the same character. Anyway create the operators and define > > maps to use them, and then fix dict/orddict/gb_trees to use them as well so > > they are compatible. I could survive potential backwards compatibility > > problems with them to achieve consistency. > > I'm thinking of writing another EEP. I did a test implementation of <:<, >:>, > =:<, >:= this weekend to see how it would pan out. See, > https://github.com/psyeugenic/otp/commits/egil/total-order-relops for > details. Seemed ok. The syntax can be changed to suite prolog heritage but > the @... syntax freak me out to be honest =) > Also what should we do with =:= vs @== and =/= vs @/= in that case? Should we > have two operators with the same meaning? > > - I also definitely agree to keep the syntactic footprint to a minimum and > > introduce as little new syntax as possible. > > Check. > > - For map comprehensions I would NOT use <- as the generator operator as it > > tells me we are generating elements from a list. Binaries got a new > > operator > > and I think maps should as well, for example <:, or something else. > > There are currently no generator implemented, and it might not be implemented > either. Also, I think K := V <- Map works for the visual and it is > definitely unique enough to be parsable. The difference of #{ K := V } <- > List vs. K := V <- Map might be to subtle though. I think we might have to > revisit this and give maps its own arrow. > Thank you! > //Bj?rn-Egil > > Robert > > > > From: "Bj?rn-Egil Dahlberg" < egil@REDACTED > > > > > > > Hi! > > > > > > Here you go, Maps! > > > > > > I've pushed a Maps branch to Erlang/OTPs repository at GitHub. > > > > > > To get the branch, > > > > > > git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation > > > > > > or find it at > > > https://github.com/erlang/otp/tree/egil/maps/eep-implementation > > > > > > I want to state the following so there is no room for uncertainty: > > > > > > - This branch contains a development stage of the experimental Maps > > > feature > > > for Erlang. > > > > > > This means: > > > > > > - Do not use it in production since it is not stable, > > > > > > - Do not base any git branch on this branch since it will most likely be > > > rebased, > > > > > > - and finally, we reserve the right to change any API or interfaces to > > > Maps > > > currently implemented. > > > > > > The implementation is based on EEP 43 - Maps, see > > > http://github.com/erlang/eep/blob/master/eeps/eep-0043.md , for details. > > > > > > What is implemented? > > > > > > The maps module API and erlang guard BIFs as defined in the EEP are > > > implemented. There are however some sematic mismatches with the EEP. I > > > think > > > those are where the definition contradict itself. For instance > > > maps:is_key/1 > > > compares with =:= as stated first in the definition but the later example > > > uses lists:keymember which compares with ==. > > > > > > The syntax and all what that entails is implemented. The compiler will > > > handle > > > the map syntax and produce loadable beam-code. I believe this is what > > > people > > > want to test and is what I want people to test. Test the usability that > > > is. > > > > > > I recommend people look at the EEP for information and also the testsuite > > > located at erts/emulator/test/map_SUITE.erl for information on how to use > > > Maps since no other documentation is available. > > > > > > Roughly, > > > > > > M0 = #{ key => Value1, "key" => Value2}, % for construction. > > > > > > M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates > > > > > > #{ "key" := V } = M1. % for matching > > > > > > Where the operator '=>' (assoc operator) is used for extending and > > > creating > > > new Maps and the operator ':=' is used to update existing key/values. The > > > ':=' operator is the only operator allowed in patterns. I'm guessing some > > > confusion will arise from these two types of operators on where you can > > > and/or should use them. > > > > > > Look at the tests and EEP for details and inspiration. > > > > > > A major difference from the EEP are variables in keys. Variables in keys > > > are > > > not allowed at all. This is because we want to reduce the scope for this > > > first stage. Plenty to do besides that. > > > > > > Here are some additional disclaimers to make people sad. > > > > > > What is not implemented? > > > > > > - No variable keys. > > > > > > - No single value access. > > > > > > - No map comprehensions. > > > > > > - No datastructure to handle large Maps. > > > > > > - No MatchSpecs which uses the Maps syntax will work. > > > > > > Known issues > > > > > > - Dialyzer will not work with maps in the code, this include PLT building > > > with erts and stdlib. > > > > > > - HiPE, the native compiler, will not with maps code. > > > > > > - EDoc will not work with maps. > > > > > > I'm sure there are other issues as well, it is a development branch after > > > all. =) > > > > > > I would also like to point out that no optimizations are done either with > > > respect to the generated code. This means that the instruction set may > > > change. We know of several optimization we want to do before R17, > > > especially > > > for the match compiler so keep that in mind. > > > > > > We will continue stabilizing the Maps implementation as we move forward > > > towards R17 and take appropriate action depending on the feedback you > > > give > > > us. > > > > > > I would like to continue with saying a few words about possible changes > > > that > > > we are thinking about. > > > > > > Variables in Keys > > > > > > This feature is actually furthest down on the work prio list. We want to > > > stabilize the current features before moving forward and variable keys is > > > the one most likely to be dropped if we get pressed for time. Meaning, it > > > might not be implemented for R17 but instead implemented for R18. The > > > plan > > > right now is to keep it though. > > > > > > The External Format > > > > > > The current external format needs ordered keys as input for > > > binary_to_term/1 > > > and in distribution. > > > > > > This is of course an inconvinience when dealing with other language > > > interfaces which has no idea of what the erlang term order is. I instead > > > propose that the external format should handle unordered input of > > > key-value > > > pairs. The trade off is a more complicated decoding which will take > > > longer. > > > > > > The distribution format should also be extended to be able cache keys. > > > This > > > is similar to the atom cache except we > > > > > > cache the entire key array for maps. This has been the intention all > > > along > > > but it not mentioned in the EEP. > > > > > > Term order and sorting > > > > > > Finally the term order. This has been a sore point from the get go. > > > > > > Maps currently respects the Erlang term order for it's keys. > > > > > > The Erlang term order is what I call arithmetic term order. I propose > > > that > > > we > > > extend Erlang with true term order where integer compares less then > > > float, > > > i.e. total term order. > > > > > > This would allowing newer ordered data structures, like maps, to be more > > > useful. We don't have to take > > > > > > special care for the odd cases like keys 1.0 and 1 inhabiting the same > > > slot > > > in the data structure. gb_trees and such structures could also be > > > extended > > > to use this as those structures has the same limitations. > > > > > > With this type ordering we could have maps with this type of keys, #{ 1 > > > => > > > "integer", 1.0 => "float" } without causing confusion. > > > > > > I've been told that ETS ordered sets tables used to have this behaviour. > > > Distinguishing between floats and integers. This was supposedly before > > > the > > > open source era, way back when dinosaurs roamed the planet .. I'm not > > > clear > > > on the details on why this behaviour was removed. Probably because of > > > inconsistencies. > > > > > > For maps to work with this I only need two things. First, a compare > > > operation > > > in the runtime that can distinguish between floats and integers, very > > > easy. > > > Secondly, a BIF that sort a list of terms with this new compare operation > > > which will be used in the compiler. > > > > > > But for completness, the following operators should also be implemented: > > > > > > =:= term exact equal to, already implemented > > > > > > =/= term not equal to, already implemented > > > > > > =:< term less or equal than > > > > > > >:= term greater or equal than > > > > > > <:< term less than > > > > > > >:> term greater than > > > > > > So, true = 1 <:< 1.0. > > > > > > I don't know prolog but perhaps these sematics should mimic prolog to > > > respect > > > Erlangs heritage. I have no strong opinion on this. > > > > > > This syntax would mimic the already present =:= and =/= relational > > > operators > > > hower this syntax is another topic and should be a seperate EEP. > > > > > > Happy testing! > > > > > > Regards, > > > > > > Bj?rn-Egil Dahlberg > > > > > > Erlang/OTP > > > > > > _______________________________________________ > > > > > > 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 Wed Oct 30 13:58:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 30 Oct 2013 13:58:35 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> Message-ID: <76179566-94F1-4055-B751-81980802335C@gmail.com> A bad record update (Arg#foo{bar=qux}) errors out with {badrecord,Arg}. A bad map update should fail with {badmap,Arg}. -- Anthony Ramine Le 30 oct. 2013 ? 13:40, Robert Virding a ?crit : > - generate 'badarg' errors instead of 'badmap' which would be consistent with other type errors. > From n.oxyde@REDACTED Wed Oct 30 14:02:07 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 30 Oct 2013 14:02:07 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <76179566-94F1-4055-B751-81980802335C@gmail.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <76179566-94F1-4055-B751-81980802335C@gmail.com> Message-ID: Err, Arg#foo{bar=qux} fails with {badrecord,foo} when Arg is not a foo record. A bad map update should fail with the atom badmap. -- Anthony Ramine Le 30 oct. 2013 ? 13:58, Anthony Ramine a ?crit : > A bad record update (Arg#foo{bar=qux}) errors out with {badrecord,Arg}. > > A bad map update should fail with {badmap,Arg}. > > -- > Anthony Ramine > > Le 30 oct. 2013 ? 13:40, Robert Virding a ?crit : > >> - generate 'badarg' errors instead of 'badmap' which would be consistent with other type errors. >> > From z_axis@REDACTED Wed Oct 30 14:19:36 2013 From: z_axis@REDACTED (z_axis) Date: Wed, 30 Oct 2013 21:19:36 +0800 Subject: [erlang-questions] R16B02 error on FreeBSD In-Reply-To: References: Message-ID: $ uname -a FreeBSD mybsd.zsoft.com 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #3 ... $ gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] Regards! ? Wed, 30 Oct 2013 17:11:46 +0800?Lukas Larsson ??: > Hello, > > You forgot to mention which gcc and FreeBSD version you are using. > > Lukas > > > On Wed, Oct 30, 2013 at 3:10 AM, z_axis wrote: > >> I am frustrated by R16B02 : "beam/erl_bif_re.c:984: error: >> 'PCRE_EXTRA_LOOP_LIMIT' undeclared (first use in this function)\n >> beam/erl_bif_re.c:986: error: 'pcre_extra' has no member named >> 'loop_limit' ..." when compiling on FreeBSD >> >> Sincerely! >> >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-questions >> -- ?? Opera ????????????: http://www.opera.com/mail/ From colanderman@REDACTED Wed Oct 30 14:26:57 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 30 Oct 2013 09:26:57 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Wed, 30 Oct 2013 08:40:44 -0400, Robert Virding wrote: > - I need functions: > > first(Map) -> {Key,Value} | error. > last(Map) -> {Key,Value} | error. > next(Key, Map) -> {Key1,Value} | error. > prev(Key, Map) -> {Key1,Value} | error. > > for stepping through maps. Have them return both key and value in one go > as it saves an explicit fetch and the extra cost is >minimal. I don't get this use case. Why do you need syntax support for a key-value map where you don't know a priori what the keys and values are? Why don't dict() and friends suffice? To me this is akin to iterating through a record/tuple. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Wed Oct 30 14:51:27 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 30 Oct 2013 14:51:27 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> Message-ID: <52710EDF.6010103@erlang.org> On 2013-10-30 14:26, Chris King wrote: > On Wed, 30 Oct 2013 08:40:44 -0400, Robert Virding > wrote: > > - I need functions: > > first(Map) -> {Key,Value} | error. > last(Map) -> {Key,Value} | error. > next(Key, Map) -> {Key1,Value} | error. > prev(Key, Map) -> {Key1,Value} | error. > > for stepping through maps. Have them return both key and value in > one go as it saves an explicit fetch and the extra cost is minimal. > Check. I'll amend the EEP. > > I don't get this use case. Why do you need syntax support for a > key-value map where you don't know a priori what the keys and values > are? Why don't dict() and friends suffice? > > To me this is akin to iterating through a record/tuple. Actually these functions are needed, at least one is needed internally, I think. It should be covered in comprehensions with Maps generators. Maps generators needs next(Key, Map). But for small Maps and record like behaviour they are not needed. =) > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Oct 30 15:03:59 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 30 Oct 2013 10:03:59 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <52710EDF.6010103@erlang.org> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> Message-ID: On Wed, 30 Oct 2013 09:51:27 -0400, Bj?rn-Egil Dahlberg wrote: > >> >> I don't get this use case. Why do you need syntax support for a >> key-value map where you don't know a priori >>what the keys and values >> are? Why don't dict() and friends suffice? >> >> To me this is akin to iterating through a record/tuple. > > Actually these functions are needed, at least one is needed internally, > I think. > > It should be covered in comprehensions with Maps generators. Maps > generators needs next(Key, Map). > > But for small Maps and record like behaviour they are not needed. =) Mm, I think I disagree about the need for map-generators as well. Couldn't that be equally well served by implementing a qlc dict() source? Well I shouldn't complain too much. Richard O'Keefe and I both argued strenuously against conflating heterogeneous (record-like) and homogeneous (dict-like) maps months ago but I guess that ship has sailed. I will just avoid using the dict-like features of these maps in my code, and hope that I am not forced to do so by the standard library or by popular applications. BTW, is there a plan for a type notation for these new maps, or for how to get Dialyzer to usefully type-check them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Wed Oct 30 15:22:00 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Wed, 30 Oct 2013 15:22:00 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <76179566-94F1-4055-B751-81980802335C@gmail.com> Message-ID: I'd say that is one case where consistency (with badrecord, at least) isn't the best policy - I've often been annoyed that the badrecord error (opposite the badmatch one) doesn't tell you what the actual value was. In most cases, the record name can be inferred from the stacktrace. The actual value is therefore far more interesting. Den 30/10/2013 14.02 skrev "Anthony Ramine" : > Err, Arg#foo{bar=qux} fails with {badrecord,foo} when Arg is not a foo > record. > > A bad map update should fail with the atom badmap. > > -- > Anthony Ramine > > Le 30 oct. 2013 ? 13:58, Anthony Ramine a ?crit : > > > A bad record update (Arg#foo{bar=qux}) errors out with {badrecord,Arg}. > > > > A bad map update should fail with {badmap,Arg}. > > > > -- > > Anthony Ramine > > > > Le 30 oct. 2013 ? 13:40, Robert Virding < > robert.virding@REDACTED> a ?crit : > > > >> - generate 'badarg' errors instead of 'badmap' which would be > consistent with other type errors. > >> > > > > _______________________________________________ > 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 Oct 30 15:24:20 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Wed, 30 Oct 2013 15:24:20 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> Message-ID: <52711694.9090500@erlang.org> On 2013-10-30 15:03, Chris King wrote: > On Wed, 30 Oct 2013 09:51:27 -0400, Bj?rn-Egil Dahlberg > wrote: > > >> >> I don't get this use case. Why do you need syntax support for a >> key-value map where you don't know a priori what the keys and >> values are? Why don't dict() and friends suffice? >> >> To me this is akin to iterating through a record/tuple. > > Actually these functions are needed, at least one is needed > internally, I think. > > It should be covered in comprehensions with Maps generators. Maps > generators needs next(Key, Map). > > But for small Maps and record like behaviour they are not needed. =) > > > Mm, I think I disagree about the need for map-generators as well. > Couldn't that be equally well served by implementing a qlc dict() source? What I meant was it needs a stepping structure internally. I don't think next(K,M) would suffice here though, need to think about it a bit more. All the comprehensions, generators, next, prev, tree structures and variables in keys goes hand in hand and those are a bit down the road. Don't fret about it =) > > Well I shouldn't complain too much. Richard O'Keefe and I both argued > strenuously against conflating heterogeneous (record-like) and > homogeneous (dict-like) maps months ago but I guess that ship has sailed. Yep. > > I will just avoid using the dict-like features of these maps in my > code, and hope that I am not forced to do so by the standard library > or by popular applications. ofc. > > BTW, is there a plan for a type notation for these new maps, or for > how to get Dialyzer to usefully type-check them? Yes. The type notation is the same as with other terms. How well Dialyzer would be able to handle it is a different matter. I plan to make them really stupid at first, meaning opaque map(). Later incarnations of dialyzer could be increasingly smarter. // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Oct 30 15:26:39 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 30 Oct 2013 10:26:39 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: Comments on the type specifications in the EEP: > Keys known before hand can be specified directly and uniquely for a map. > -spec func(Opt, M) -> #{ 'status' => S, 'c' => integer() } Does this mean the returned map must contain exactly those keys? At least those keys? At most those keys? If either of the latter, does this meaning reverse when the map is an input to the function? > spec plist_to_map(Ls) -> #{ binary() => integer() } Does this means plist_to_map must return a map containing: a) exactly one key, which is a binary; b) any number of keys, exactly one of which is a binary; c) any number of keys, at most one of which is a binary; d) any number of keys, which are all binaries; f) any number of keys, which may be any type, but those of which are binaries, must map to integers; g) same as (f), but meaning at *least* one of which is a binary; h) a map mapping every possible binary to an integer? I mention (h) only because it clearly is impossible, yet if the interpretation in the previous example is "exactly those keys" or "at least those keys", then the interpretation here must be (h) or a variant thereof. I corroborate with this example from the EEP: > -type map2() :: #{ <<"list1">> | <<"list2">> => [numbers()] }. which implies that the key types are not special-cased for atoms. Therefore, we can conclude that a map type-specification on the RHS of a function must mean "a map containing at most those keys"; which, while useful for the "dict" usage, is hardly useful for "record" usage. Knowing only that the returned map does *not* contain most keys is useless when I'm trying to ensure that it contains the one key I'm interested in. The best way to fix this IMO is to separate homogeneous and heterogeneous maps. Homogeneous map types can then have "at most" semantics (to support iteration), while heterogeneous map types can have "at least" semantics (to support lookup). -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Oct 30 15:38:35 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 30 Oct 2013 10:38:35 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <52711694.9090500@erlang.org> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> Message-ID: On Wed, 30 Oct 2013 10:24:20 -0400, Bj?rn-Egil Dahlberg wrote: > >> BTW, is there a plan for a type notation for these new maps, or for how >> to get Dialyzer to usefully >>type-check them? > > Yes. The type notation is the same as with other terms. Ya, I just found that and posted a separate e-mail with my analysis. I believe the type signatures to be inconsistently specified. > How well Dialyzer would be able to handle it is a different matter. I > plan to make them really stupid at first, >meaning opaque map(). Later > incarnations of dialyzer could be increasingly smarter. I think it will be very difficult for Dialyzer to automatically tease apart the homogeneous (list-like) and heterogeneous (tuple-like) use cases, even if they are not mixed. In particular, as I mentioned in my other e-mail, the useful type variance in the heterogeneous use case is the opposite of the useful type variance in the homogeneous case. (i.e., we want to know that a heterogeneous map contains *at least* some keys; we want to know that a homogeneous map contains *at most* some keys). Maybe I am wrong ? I hope I am ? but without a plan and without the hetero-homogeneous distinction, I fear "later" could be "never". -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Oct 30 15:42:22 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 30 Oct 2013 15:42:22 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <76179566-94F1-4055-B751-81980802335C@gmail.com> Message-ID: I agree with you, hence my confusion with the second tuple element at first. Btw if you sometimes want better errors when developing, shameless plug for my Shippai core transform which makes use of error/2 instead of error/1: https://github.com/nox/shippai :) -- Anthony Ramine Le 30 oct. 2013 ? 15:22, Erik S?e S?rensen a ?crit : > I've often been annoyed that the badrecord error (opposite the badmatch one) doesn't tell you what the actual value was. In most cases, the record name can be inferred from the stacktrace. The actual value is therefore far more interesting. From egil@REDACTED Wed Oct 30 15:57:43 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Wed, 30 Oct 2013 15:57:43 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> Message-ID: <52711E67.5020605@erlang.org> On 2013-10-30 15:38, Chris King wrote: > On Wed, 30 Oct 2013 10:24:20 -0400, Bj?rn-Egil Dahlberg > wrote: > > >> BTW, is there a plan for a type notation for these new maps, or >> for how to get Dialyzer to usefully type-check them? > > Yes. The type notation is the same as with other terms. > > > Ya, I just found that and posted a separate e-mail with my analysis. > I believe the type signatures to be inconsistently specified. > > > How well Dialyzer would be able to handle it is a different > matter. I plan to make them really stupid at first, meaning opaque > map(). Later incarnations of dialyzer could be increasingly smarter. > > > I think it will be very difficult for Dialyzer to automatically tease > apart the homogeneous (list-like) and heterogeneous (tuple-like) use > cases, even if they are not mixed. In particular, as I mentioned in > my other e-mail, the useful type variance in the heterogeneous use > case is the opposite of the useful type variance in the homogeneous > case. (i.e., we want to know that a heterogeneous map contains *at > least* some keys; we want to know that a homogeneous map contains *at > most* some keys). > > Maybe I am wrong ? I hope I am ? but without a plan and without the > hetero-homogeneous distinction, I fear "later" could be "never". First, I'm far from a Dialyzer expert .. However, I think we can view maps as functions and the pairs as function clauses. It should be the same problem space, i.e. range and domains, product and unions. so, -spec wat() -> #{ binary() => integer()}. would exhibit the same problem/solution as, -spec foo(binary()) -> integer(). foo(B) when is_binary(B) -> binary_to_integer(B). That's my view at least, I could very well be wrong also here. But as I said, for a first stab at it, it should be strictly opaque map(). I've looked at your other mail but I don't have time to get into the details right now. Thank you for feedback! It is much appreciated and I will look into it when the time arrives! // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Oct 30 16:13:51 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 30 Oct 2013 11:13:51 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <52711E67.5020605@erlang.org> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> <52711E67.5020605@erlang.org> Message-ID: On Wed, 30 Oct 2013 10:57:43 -0400, Bj?rn-Egil Dahlberg wrote: > However, I think we can view maps as functions and the pairs as function > clauses. It should be the same problem >space, i.e. range and domains, > product and unions. > > so, > > -spec wat() -> #{ binary() => integer()}. > > would exhibit the same problem/solution as, > > -spec foo(binary()) -> integer(). > > foo(B) when is_binary(B) -> binary_to_integer(B). That works for heterogeneous maps (i.e. supporting selection). But for the example you give (a homogeneous map, supporting enumeration) this fails, as that signature requires that the function be defined for *all* binaries. Clearly this is impossible! -spec foo(Key1) -> Value1Type. -spec foo(Key2) -> Value2Type. works for heterogeneous maps, but not homogeneous maps. For a homogeneous map, the signature you need is: -spec foo(KeyType) -> {ok, ValueType} | none. because "Key" here is necessarily a full type rather than a single value or two, and the map, being finite, cannot contain a value for every possible key. > I've looked at your other mail but I don't have time to get into the > details right now.Thank you for feedback! It is much appreciated and I > will look into it when the time arrives! Thanks for listening. I come from the OCaml world which *almost* has heterogeneous maps done right (its object types); AFAIK no other language does (beside SQL), hence why I am so engaged :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Wed Oct 30 16:20:20 2013 From: garazdawi@REDACTED (Lukas Larsson) Date: Wed, 30 Oct 2013 16:20:20 +0100 Subject: [erlang-questions] R16B02 error on FreeBSD In-Reply-To: References: Message-ID: Hello, R16B02 compiles fine on our FreeBSD 9.1 with the same gcc version as you have. What seems to happen is that when including "pcre.h" gcc decides to use the system "pcre.h" rather then the erts version. I found a potential workaround here: https://github.com/iriscouch/build-couchdb/issues/56. i.e. move the $(INCLUDE) found here[1] to before the $(subst, ...). Let me know if that works for you. Lukas [1]: https://github.com/erlang/otp/blob/maint/erts/emulator/Makefile.in#L656 On Wed, Oct 30, 2013 at 2:19 PM, z_axis wrote: > $ uname -a > FreeBSD mybsd.zsoft.com 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #3 ... > > $ gcc -v > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > > Regards! > > ? Wed, 30 Oct 2013 17:11:46 +0800?Lukas Larsson ??: > > Hello, >> >> You forgot to mention which gcc and FreeBSD version you are using. >> >> Lukas >> >> >> On Wed, Oct 30, 2013 at 3:10 AM, z_axis wrote: >> >> I am frustrated by R16B02 : "beam/erl_bif_re.c:984: error: >>> 'PCRE_EXTRA_LOOP_LIMIT' undeclared (first use in this function)\n >>> beam/erl_bif_re.c:986: error: 'pcre_extra' has no member named >>> 'loop_limit' ..." when compiling on FreeBSD >>> >>> Sincerely! >>> >>> ______________________________****_________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/****listinfo/erlang-questions >>> >>> > >>> >>> > > -- > ?? Opera ????????????: http://www.opera.com/mail/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Oct 30 16:36:12 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 30 Oct 2013 16:36:12 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> <52711E67.5020605@erlang.org> Message-ID: <5152413E-0FEB-4073-9260-9E7C3C4B5BAC@gmail.com> In the foo/1 spec, the binary() doesn?t mean that foo/1 handles *all* binaries, it means that if you give something that is not a binary(), the call is guaranteed to fail. PS: Your MUA sends rich text in 12px. -- Anthony Ramine Le 30 oct. 2013 ? 16:13, Chris King a ?crit : > On Wed, 30 Oct 2013 10:57:43 -0400, Bj?rn-Egil Dahlberg wrote: > > However, I think we can view maps as functions and the pairs as function clauses. It should be the same problem space, i.e. range and domains, product and unions. > > so, > > -spec wat() -> #{ binary() => integer()}. > > would exhibit the same problem/solution as, > > -spec foo(binary()) -> integer(). > > foo(B) when is_binary(B) -> binary_to_integer(B). > > That works for heterogeneous maps (i.e. supporting selection). But for the example you give (a homogeneous map, supporting enumeration) this fails, as that signature requires that the function be defined for *all* binaries. Clearly this is impossible! > > -spec foo(Key1) -> Value1Type. > -spec foo(Key2) -> Value2Type. > > works for heterogeneous maps, but not homogeneous maps. For a homogeneous map, the signature you need is: > > -spec foo(KeyType) -> {ok, ValueType} | none. > > because "Key" here is necessarily a full type rather than a single value or two, and the map, being finite, cannot contain a value for every possible key. > > > I've looked at your other mail but I don't have time to get into the details right now. > Thank you for feedback! It is much appreciated and I will look into it when the time arrives! > > Thanks for listening. I come from the OCaml world which *almost* has heterogeneous maps done right (its object types); AFAIK no other language does (beside SQL), hence why I am so engaged :) > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Wed Oct 30 16:42:03 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 30 Oct 2013 16:42:03 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> <52711E67.5020605@erlang.org> Message-ID: On Wed, Oct 30, 2013 at 4:13 PM, Chris King wrote: > Thanks for listening. I come from the OCaml world which *almost* has > heterogeneous maps done right (its object types); AFAIK no other language > does (beside SQL), hence why I am so engaged :) My guess would be that there is a subtyping construction at play here. And they usually require both covariance and contravariance in input/outputs to functions. Luckily, the dialyzer is able to be more lenient and can just give up typing if possible and call it a map(). But that will not buy you much static verification, sadly. What one could do is to handle the homogenous case well in the dialyzer. This should be fairly straightforward if one can provide a witness that only homogenous values gets added. This doesn't solve the heterogenous case though. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Wed Oct 30 16:48:33 2013 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 30 Oct 2013 16:48:33 +0100 (CET) Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> Message-ID: <1725932636.423910.1383148113477.JavaMail.zimbra@erlang-solutions.com> ----- Original Message ----- > From: "Chris King" > On Wed, 30 Oct 2013 08:40:44 -0400, Robert Virding > wrote: > > - I need functions: > > > first(Map) -> {Key,Value} | error. > > > last(Map) -> {Key,Value} | error. > > > next(Key, Map) -> {Key1,Value} | error. > > > prev(Key, Map) -> {Key1,Value} | error. > > > for stepping through maps. Have them return both key and value in one go as > > it saves an explicit fetch and the extra cost is minimal. > > I don't get this use case. Why do you need syntax support for a key-value map > where you don't know a priori what the keys and values are? Why don't dict() > and friends suffice? > To me this is akin to iterating through a record/tuple. I need this ability to step through a map/dict/whatever in an application I am working on (luerl). Dict does not provide this type of functionality. It would be easy to hack into an orddict but I don't want to use lists. Gb_trees provides an iterators but they are quite limited in that they only allow you to step through the whole tree from beginning to end; you can't jump in in the middle. Which I need to be able to do. I solved this by writing my own dict compatible module, ttdict, based on 2-3 trees where I added these 4 extra functions. Ttdict was quite good and provided dict API on ordered keys which is faster than gb_trees. I had planned to add it to the libraries but with maps the need for it has more or less disappeared. I think. My idea was that now maps are coming I could replace ttdict with maps, not for functionality but for speed. Hence the request for the extra functions. I am assuming that doing it in C will be faster than doing it in Erlang. What would be interesting to see is how much faster you could get a dict replacement which uses hashing and doesn't give key ordering. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Oct 30 17:07:55 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 30 Oct 2013 12:07:55 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <5152413E-0FEB-4073-9260-9E7C3C4B5BAC@gmail.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> <52711E67.5020605@erlang.org> <5152413E-0FEB-4073-9260-9E7C3C4B5BAC@gmail.com> Message-ID: On Wed, 30 Oct 2013 11:36:12 -0400, Anthony Ramine wrote: > In the foo/1 spec, the binary() doesn?t mean that foo/1 handles *all* > binaries, it means that if you give something that is not a binary(), > the call is guaranteed to fail. Mm, the Erlang reference manual is unclear about the correct interpretation. Dialyzer's interpretation differs with the -Wunderspecs flag: $ cat > foo.erl -module(foo). -export([bar/1]). -spec bar(integer()) -> ok. bar(42) -> ok. $ dialyzer foo.erl done (passed successfully) $ dialyzer -Wunderspecs foo.erl foo.erl:3: Type specification foo:bar(integer()) -> 'ok' is a supertype of the success typing: foo:bar(42) -> 'ok' done (warnings were emitted) The latter is more useful to me ? I would like to know from the spec that a function can handle certain inputs (or, in the case of a heterogeneous map, will produce certain outputs). Knowing that "the function will return this type or crash" is less useful. (And the benefit from this interpretation ? knowing that given certain inputs, the function will *definitely* crash, is not generally useful (and I have used languages where this is expressible). I realize that internally this is how Dialyzer works, but that does not mean the type language must work his way.) Without a firm definition, it's not possible to say how function specs "should" be interpreted. FWIW Dialyzer *can* (with -Wunderspecs) check the heterogeneous map type-analogous case of a function returning a function. (i.e. it can check that the returned function accepts at *least* the specified values; just as with a heterogeneous map, we care whether it contains at *least* the specified keys.) > PS: Your MUA sends rich text in 12px. *checks settings* Ah, it was set to "prefer text/reply with same formatting". Fixed, thanks. From colanderman@REDACTED Wed Oct 30 17:13:16 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 30 Oct 2013 12:13:16 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <1725932636.423910.1383148113477.JavaMail.zimbra@erlang-solutions.com> References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <1725932636.423910.1383148113477.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Wed, 30 Oct 2013 11:48:33 -0400, Robert Virding wrote: > I need this ability to step through a map/dict/whatever in an > application I am working on (luerl). Dict does not provide this type of > functionality. It would be easy to hack into an orddict but I don't want > to use lists. Gb_trees provides an iterators but they are quite limited > in that they only allow you to step through the whole tree from > beginning to end; you can't jump in in the middle. Which I need to be > able to do. That answers why you need iteration through a homogeneous map-like data structure. I get that. But why does that need to be joined with syntax support? (My thesis is that syntax support and iteration apply to two distinct use cases of key-value maps, and that they should be kept separate rather than piggybacking on each other, in order to permit better optimization, to decouple development, and to simplify typechecking.) From egil@REDACTED Wed Oct 30 17:50:22 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 30 Oct 2013 17:50:22 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <526A9E59.7090406@erlang.org> References: <526A9E59.7090406@erlang.org> Message-ID: <527138CE.4060809@erlang.org> I've pushed some fixes mentioned in this thread to the otp repo at GitHub. - Tomas Abrahamsson reported a compiler bug. A failure label jump within an allocate/deallocate block. This has been fixed, my Canucks beats the Blues solution was correct. - Pierre Fenoll reported that fcall()#{ ... }did not compile. I'm still iffy about a using a call expression directly. However (fcall())#{ ... }did not compile either and this has been fixed. Maps operating on expressions, not only variables, are now made safe in v3_core. As for call expressions directly .. I will take it under consideration. - Daniel Goertzen reported that maps:map/2 was not working as intended. This goes to show that, code that is not tested does not work. maps:map/2 has been fixed and tests has been added for the non-bifs. =) I will sprinkle these kind of fixes to the branch in the otp repo. // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Wed Oct 30 18:11:17 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Wed, 30 Oct 2013 18:11:17 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: <527138CE.4060809@erlang.org> References: <526A9E59.7090406@erlang.org> <527138CE.4060809@erlang.org> Message-ID: Sorry for the screaming text. Thunderbird did not show this problem =o - Tomas Abrahamsson reported a compiler bug. A failure label jump within an allocate/deallocate block. This has been fixed, my Canucks beats the Blues solution was correct. - Pierre Fenoll reported that fcall()#{ ... } did not compile. I'm still iffy about a using a call expression directly. However (fcall())#{ ... } did not compile either and this has been fixed. Maps operating on expressions, not only variables, are now made safe in v3_core. As for call expressions directly .. I will take it under consideration. - Daniel Goertzen reported that maps:map/2 was not working as intended. This goes to show that, code that is not tested does not work. maps:map/2 has been fixed and tests has been added for the non-bifs. =) 2013/10/30 Bj?rn-Egil Dahlberg > I've pushed some fixes mentioned in this thread to the otp repo at GitHub. > > - Tomas Abrahamsson reported a compiler bug. A failure label jump within > an allocate/deallocate block. > This has been fixed, my Canucks beats the Blues solution was correct. > > - Pierre Fenoll reported that fcall()#{ ... } did not compile. > I'm still iffy about a using a call expression directly. However (fcall())#{ > ... } did not compile either and this has been fixed. Maps operating on > expressions, not only variables, are now made safe in v3_core. As for > call expressions directly .. I will take it under consideration. > > - Daniel Goertzen reported that maps:map/2 was not working as intended. > This goes to show that, code that is not tested does not work. > maps:map/2 has been fixed and tests has been added for the non-bifs. =) > > I will sprinkle these kind of fixes to the branch in the otp repo. > > // Bj?rn-Egil > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity@REDACTED Wed Oct 30 19:42:52 2013 From: icfp.publicity@REDACTED (David Van Horn) Date: Wed, 30 Oct 2013 14:42:52 -0400 Subject: [erlang-questions] ICFP 2014: Call for Workshop & Co-located Even Proposals Message-ID: CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2014 19th ACM SIGPLAN International Conference on Functional Programming August 31 ? September 6, 2014 Gothenburg, Sweden http://icfpconference.org/icfp2014/ The 19th ACM SIGPLAN International Conference on Functional Programming will be held in Gothenburg, Sweden on August 31-September 6, 2014. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2014 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on August 31 (the day before ICFP) and September 4-6 (the three days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 15, 2013 Notification of acceptance: December 15, 2013 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2014 workshop co-chairs (Sam Tobin-Hochstadt and Tom Schrijvers), via email to icfp2014-workshops@REDACTED by November 15, 2013. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 15, 2013, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2014/icfp14-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2014 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Sam Tobin-Hochstadt (Indiana University) Workshop Co-Chair: Tom Schrijvers (Ghent University) General Chair : Johan Jeuring (Utrecht University) Program Chair: Manuel Chakravarty (University of New South Wales) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Sam Tobin-Hochstadt and Tom Schrijvers), via email to icfp2014-workshops@REDACTED From martynasp@REDACTED Wed Oct 30 21:41:32 2013 From: martynasp@REDACTED (Martynas Pumputis) Date: Wed, 30 Oct 2013 21:41:32 +0100 Subject: [erlang-questions] Workflow process model In-Reply-To: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> References: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> Message-ID: <52716EFC.7090801@gmail.com> Having done both approaches (one with "business process as an Erlang process" and the other "database-centric with bunch of workers"), I would suggest to answer yourself the following questions: * is persistence needed? you might want to store either each incoming/outgoing event or events + state transitions for each process. The latter is needed, if your transitions have side effects which can't be reflected by events and in a case of failure your system global state can't be restored from events. * do you need fault-tolerance ? Erlangish approach requires you to ensure that only the one instance is running at given time (hence, leader election). * are transitions triggered only by request messages ? if not, then you will need timers. it comes out of the box with Erlang processes. you probably just want them to survive process crashes. implementing timers might be quite painful, if your BP can be handled by any worker residing on any node and you don't want to send duplicated timer events. * live process logic (code) upgrade, do you need it or maybe you can stop the system for doing that ? * how many running instances do you plan to have at once? * how many different types of process ? anyway, you will implement your own generic behaviour. Martynas On 10/29/2013 08:02 PM, Charles Irvine wrote: > I plan to write a BPM (Workflow) engine in Erlang. I?m struggling with what the process model ought to be. Suggestions would be greatly appreciated. Here?s the general structure of the system: > > Users construct a process model for an purposeful activity. Let?s say the activity is to fix a software defect. The process model is a set of tasks sequenced to achieve the goal of the process. The process model for fixing a defect would be: > > OpenDefect -> WriteCodeToFixDefect -> DeployFixCodeToTestEnv -> TestFix -> DeployCodeToProd > > A single instance of this flow of task completion I call a workflow instance. There may be a large number of such instances in progress concurrently. The state of a workflow instance is a set of outstanding tasks ready to be performed and what I call a workflow context. A workflow context is a set of informational artifacts accumulated as the workflow progresses. > > For example the state of defect resolution workflow instance might be an instance of the task WriteCodeToFixDefect and the context would be a defect description. > > I?ve considered making each such workflow instance a process but I hesitate to do this since a process may have a relatively long lifetime and there might be a long duration between significant events. For example, a defect might not get fixed for weeks or months and a long time could elapse between the time the defect is reported and the time that someone starts working on it. > > A little nudge or two from folks more skilled than me at this would be much appreciated. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From chuck.irvine@REDACTED Thu Oct 31 00:03:04 2013 From: chuck.irvine@REDACTED (Charles Irvine) Date: Wed, 30 Oct 2013 18:03:04 -0500 Subject: [erlang-questions] Workflow process model In-Reply-To: <5270B4FB.8010208@gmail.com> References: <07FC5095-A90F-4D6B-9053-6114B0D884CE@icloud.com> <5270B4FB.8010208@gmail.com> Message-ID: I am very grateful to the individuals that responded to my post. There were several good ideas and some pointers to things I need to become more familiar with. Originally in my career, many years ago now, I programmed in Lisp. Coming back to a functional programming language after spending so long in the Tower of Babel that is OO is very refreshing. Cheers and thanks. On Oct 30, 2013, at 2:27 AM, Motiejus Jak?tys wrote: > 2013.10.29 20:02, Charles Irvine ra??: >> I?ve considered making each such workflow instance a process but I >> hesitate to do this since a process may have a relatively long >> lifetime and there might be a long duration between significant >> events. For example, a defect might not get fixed for weeks or months >> and a long time could elapse between the time the defect is reported >> and the time that someone starts working on it. >> >> A little nudge or two from folks more skilled than me at this would >> be much appreciated. > > I (together with a few people in this mailing list) created a tool to manage number portability database (when you migrate your phone number from one operator to another, some entity has to mediate it) on national scale. A single process is responsible for a single transaction, which includes a range of numbers. Transactions can last from 1 day to years. A process is a state machine which just sends messages to operators according to some rules. > > One transaction is an erlang process, which, if does not receive a message for 60 minutes, hibernates. When you hibernate, you do not worry about the number of processes. We also had distribution, so there was no practical ceiling. > > For recovery and audit purposes you can log every incoming/outgoing message. That will let you reply all transactions and return to the state before crash (we did it wrong way, but later realized that this should have been done instead). > > So in short, stick to the process model and, if you are worried about number of them, hibernate. I just tried running 1M hibernated processes on a 64bit laptop. Takes 866M residential memory. Of course, yours will take more depending on size of your state. But still it's cheap. > > Motiejus From robert.virding@REDACTED Thu Oct 31 00:49:36 2013 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 31 Oct 2013 00:49:36 +0100 (CET) Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <1725932636.423910.1383148113477.JavaMail.zimbra@erlang-solutions.com> Message-ID: <1252743358.493184.1383176976754.JavaMail.zimbra@erlang-solutions.com> ----- Original Message ----- > From: "Chris King" > Sent: Wednesday, 30 October, 2013 5:13:16 PM > > On Wed, 30 Oct 2013 11:48:33 -0400, Robert Virding > wrote: > > > I need this ability to step through a map/dict/whatever in an > > application I am working on (luerl). Dict does not provide this type of > > functionality. It would be easy to hack into an orddict but I don't want > > to use lists. Gb_trees provides an iterators but they are quite limited > > in that they only allow you to step through the whole tree from > > beginning to end; you can't jump in in the middle. Which I need to be > > able to do. > > That answers why you need iteration through a homogeneous map-like data > structure. I get that. > > But why does that need to be joined with syntax support? No, I don't think it does need to be joined with syntax support. I would have preferred a split solution which provided dynamic records with syntax support and a natively implemented dict module to get it faster. I personally have no need of special syntax when using it as a dictionary and, at least for me, it doesn't give any benefits. You need one for the dynamic records of course. I was just checking through dict and I see that I actually wrote code for the functions first and next but they are commented out. I guess to preserve the API. The only difference is that they return only the key. A trivial fix. That would actually do for me. :-) Robert From z_axis@REDACTED Thu Oct 31 01:45:15 2013 From: z_axis@REDACTED (z_axis) Date: Thu, 31 Oct 2013 08:45:15 +0800 Subject: [erlang-questions] R16B02 error on FreeBSD In-Reply-To: References: Message-ID: It seems work now ! thanks! ? Wed, 30 Oct 2013 23:20:20 +0800?Lukas Larsson ??: > $(INCLUDE -- ?? Opera ????????????: http://www.opera.com/mail/ From matthias@REDACTED Thu Oct 31 11:27:33 2013 From: matthias@REDACTED (Matthias Lang) Date: Thu, 31 Oct 2013 11:27:33 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? Message-ID: <20131031102733.GA6528@corelatus.se> Hi, TLDR: Whenever an Erlang process dies an abnormal death, there's some code deep in the VM which sends an unstructured message to error_logger about the death. This was surprising to me. The Question ------------ I was going to ask "where does this 'ERROR REPORT' message come from?": ~ >erl -boot start_sasl Erlang R15B03 (erts-5.9.3.1)... ... 1> spawn(fun() -> 3 = 9 end). <0.42.0> 2> =ERROR REPORT==== 31-Oct-2013::10:51:47 === Error in process <0.42.0> with exit value: {{badmatch,9},[{erl_eval,expr,3,[]}]} But before asking, I dug out the answer myself. So this post is a question with the answer supplied. Hope someone's interested. Anyway, this "Error in process <0.42.0>" message, how can that possibly work? Impossible answers ------------------ No Erlang process is linked to <0.42.0>---I used plain spawn()---so it can't work through links. No Erlang process is monitoring <0.42.0>, so that's out too. I even checked that there's no tracing on. There isn't. I can't find anything in the 'Barklund Draft' which says that abnormal process death should give information to another process through any other mechanism. So, this is a top secret part of Erlang, available only to helmeted, blonde, bearded eaters of rotten fish. The actual answer ----------------- Deep in "beam_emu.c", there's terminate_proc(). Here's what it does: erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value); erts_send_error_to_logger(c_p->group_leader, dsbufp); So, the exit value term, i.e. {badmatch, 9} and the stack trace is turned into a string (!) and then sent to the process registered as 'error_logger'. It seems OTP invaded the Erlang VM a bit... The other times I've seen the VM send messages to the error logger, it's because something's on fire, e.g. distribution has gone nuts. Not something mundane like a process dying. Seems like a quick hack left over from long ago. The fix ------- If you implement your own error_logger, it's tempting to match these messages so you can do things with them---you might want to format them differently, or someone might have a burning need to translate them to Maori---but this is unpalatable because the message comes as a string. That leaves the approach taken by proc_lib:spawn(), which is to wrap the spawned code in a 'try', which means the VM never gets its fingers on that crash. And that then gets you back to what I expected: if I spawn() a process, I want it to just die quietly, even if it crashes. Shame that's not the default. Matt From n.oxyde@REDACTED Thu Oct 31 11:51:36 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 31 Oct 2013 11:51:36 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <20131031102733.GA6528@corelatus.se> References: <20131031102733.GA6528@corelatus.se> Message-ID: <8F3B649A-C7A8-471E-A85B-0B738E6D51B4@gmail.com> Even if we sent a structured term to the error logger, we would need to limit its size because the error term and stack trace is copied on the error logger heap and can be very very huge. Shameless plug: my better-error-reports (IIRC the name, can't check right now) aims first to improve stack trace formatting and second to improve the terms sent to the error logger. -- Anthony Ramine > Le 31 oct. 2013 ? 11:27, Matthias Lang a ?crit : > > Hi, > > TLDR: Whenever an Erlang process dies an abnormal death, there's some > code deep in the VM which sends an unstructured message to > error_logger about the death. This was surprising to me. > > > The Question > ------------ > > I was going to ask "where does this 'ERROR REPORT' message come from?": > > ~ >erl -boot start_sasl > Erlang R15B03 (erts-5.9.3.1)... > ... > 1> spawn(fun() -> 3 = 9 end). > <0.42.0> > 2> > =ERROR REPORT==== 31-Oct-2013::10:51:47 === > Error in process <0.42.0> with exit value: {{badmatch,9},[{erl_eval,expr,3,[]}]} > > But before asking, I dug out the answer myself. So this post is a > question with the answer supplied. Hope someone's interested. > > Anyway, this "Error in process <0.42.0>" message, how can that > possibly work? > > > Impossible answers > ------------------ > > No Erlang process is linked to <0.42.0>---I used plain spawn()---so it > can't work through links. > > No Erlang process is monitoring <0.42.0>, so that's out too. > > I even checked that there's no tracing on. There isn't. > > I can't find anything in the 'Barklund Draft' which says that abnormal > process death should give information to another process through any > other mechanism. So, this is a top secret part of Erlang, available > only to helmeted, blonde, bearded eaters of rotten fish. > > > The actual answer > ----------------- > > Deep in "beam_emu.c", there's terminate_proc(). Here's what it does: > > erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); > erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); > erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value); > erts_send_error_to_logger(c_p->group_leader, dsbufp); > > So, the exit value term, i.e. {badmatch, 9} and the stack trace is > turned into a string (!) and then sent to the process registered as > 'error_logger'. > > It seems OTP invaded the Erlang VM a bit... The other times I've seen > the VM send messages to the error logger, it's because something's on > fire, e.g. distribution has gone nuts. Not something mundane like a > process dying. Seems like a quick hack left over from long ago. > > > The fix > ------- > > If you implement your own error_logger, it's tempting to match these > messages so you can do things with them---you might want to format > them differently, or someone might have a burning need to translate > them to Maori---but this is unpalatable because the message comes as a > string. > > That leaves the approach taken by proc_lib:spawn(), which is to wrap > the spawned code in a 'try', which means the VM never gets its fingers > on that crash. And that then gets you back to what I expected: if I > spawn() a process, I want it to just die quietly, even if it > crashes. Shame that's not the default. > > Matt > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Thu Oct 31 11:58:18 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 31 Oct 2013 11:58:18 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> <52711E67.5020605@erlang.org> <5152413E-0FEB-4073-9260-9E7C3C4B5BAC@gmail.com> Message-ID: Write an unary function with 15 (might need more) different clauses f(a1) -> ...; ...; f(a15) -> .... Dialyzer will infer atom() for the argument type because large type unions are broadened to make the various type unifications happen in a reasonable time, if I understand this correctly. This kind of validates what I said about types being used to reject sure-to-fail calls. At least that's how I see success typing as opposed to more traditional type systems. I may be completely wrong. -- Anthony Ramine > Le 30 oct. 2013 ? 17:07, "Chris King" a ?crit : > >> On Wed, 30 Oct 2013 11:36:12 -0400, Anthony Ramine wrote: >> >> In the foo/1 spec, the binary() doesn?t mean that foo/1 handles *all* binaries, it means that if you give something that is not a binary(), the call is guaranteed to fail. > > Mm, the Erlang reference manual is unclear about the correct interpretation. Dialyzer's interpretation differs with the -Wunderspecs flag: > > $ cat > foo.erl > -module(foo). > -export([bar/1]). > -spec bar(integer()) -> ok. > bar(42) -> ok. > > $ dialyzer foo.erl > done (passed successfully) > > $ dialyzer -Wunderspecs foo.erl > foo.erl:3: Type specification foo:bar(integer()) -> 'ok' is a supertype of the success typing: foo:bar(42) -> 'ok' > done (warnings were emitted) > > The latter is more useful to me ? I would like to know from the spec that a function can handle certain inputs (or, in the case of a heterogeneous map, will produce certain outputs). Knowing that "the function will return this type or crash" is less useful. > > (And the benefit from this interpretation ? knowing that given certain inputs, the function will *definitely* crash, is not generally useful (and I have used languages where this is expressible). I realize that internally this is how Dialyzer works, but that does not mean the type language must work his way.) > > Without a firm definition, it's not possible to say how function specs "should" be interpreted. > > > FWIW Dialyzer *can* (with -Wunderspecs) check the heterogeneous map type-analogous case of a function returning a function. (i.e. it can check that the returned function accepts at *least* the specified values; just as with a heterogeneous map, we care whether it contains at *least* the specified keys.) > > >> PS: Your MUA sends rich text in 12px. > > *checks settings* Ah, it was set to "prefer text/reply with same formatting". Fixed, thanks. From pierrefenoll@REDACTED Thu Oct 31 12:11:33 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Thu, 31 Oct 2013 11:11:33 +0000 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <8F3B649A-C7A8-471E-A85B-0B738E6D51B4@gmail.com> References: <20131031102733.GA6528@corelatus.se> <8F3B649A-C7A8-471E-A85B-0B738E6D51B4@gmail.com> Message-ID: There, nox: https://github.com/nox/otp/compare/better-error-reports (BTW you seem to have a mix of tabs and spaces in your code) Cheers, -- Pierre Fenoll On 31 October 2013 10:51, Anthony Ramine wrote: > Even if we sent a structured term to the error logger, we would need to > limit its size because the error term and stack trace is copied on the > error logger heap and can be very very huge. > > Shameless plug: my better-error-reports (IIRC the name, can't check right > now) aims first to improve stack trace formatting and second to improve the > terms sent to the error logger. > > -- > Anthony Ramine > > > Le 31 oct. 2013 ? 11:27, Matthias Lang a ?crit : > > > > Hi, > > > > TLDR: Whenever an Erlang process dies an abnormal death, there's some > > code deep in the VM which sends an unstructured message to > > error_logger about the death. This was surprising to me. > > > > > > The Question > > ------------ > > > > I was going to ask "where does this 'ERROR REPORT' message come from?": > > > > ~ >erl -boot start_sasl > > Erlang R15B03 (erts-5.9.3.1)... > > ... > > 1> spawn(fun() -> 3 = 9 end). > > <0.42.0> > > 2> > > =ERROR REPORT==== 31-Oct-2013::10:51:47 === > > Error in process <0.42.0> with exit value: > {{badmatch,9},[{erl_eval,expr,3,[]}]} > > > > But before asking, I dug out the answer myself. So this post is a > > question with the answer supplied. Hope someone's interested. > > > > Anyway, this "Error in process <0.42.0>" message, how can that > > possibly work? > > > > > > Impossible answers > > ------------------ > > > > No Erlang process is linked to <0.42.0>---I used plain spawn()---so it > > can't work through links. > > > > No Erlang process is monitoring <0.42.0>, so that's out too. > > > > I even checked that there's no tracing on. There isn't. > > > > I can't find anything in the 'Barklund Draft' which says that abnormal > > process death should give information to another process through any > > other mechanism. So, this is a top secret part of Erlang, available > > only to helmeted, blonde, bearded eaters of rotten fish. > > > > > > The actual answer > > ----------------- > > > > Deep in "beam_emu.c", there's terminate_proc(). Here's what it does: > > > > erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); > > erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); > > erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value); > > erts_send_error_to_logger(c_p->group_leader, dsbufp); > > > > So, the exit value term, i.e. {badmatch, 9} and the stack trace is > > turned into a string (!) and then sent to the process registered as > > 'error_logger'. > > > > It seems OTP invaded the Erlang VM a bit... The other times I've seen > > the VM send messages to the error logger, it's because something's on > > fire, e.g. distribution has gone nuts. Not something mundane like a > > process dying. Seems like a quick hack left over from long ago. > > > > > > The fix > > ------- > > > > If you implement your own error_logger, it's tempting to match these > > messages so you can do things with them---you might want to format > > them differently, or someone might have a burning need to translate > > them to Maori---but this is unpalatable because the message comes as a > > string. > > > > That leaves the approach taken by proc_lib:spawn(), which is to wrap > > the spawned code in a 'try', which means the VM never gets its fingers > > on that crash. And that then gets you back to what I expected: if I > > spawn() a process, I want it to just die quietly, even if it > > crashes. Shame that's not the default. > > > > Matt > > _______________________________________________ > > 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 Thu Oct 31 12:43:53 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 31 Oct 2013 12:43:53 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: References: <20131031102733.GA6528@corelatus.se> <8F3B649A-C7A8-471E-A85B-0B738E6D51B4@gmail.com> Message-ID: Re: indentation: blame the Emacs mode which uses GNU style indents: X spaces, replace any consecutive 8 spaces by a hard tab. It's quite clever in fact but most tools (especially that damn GitHub) can't cope with it cleanly. -- Anthony Ramine > Le 31 oct. 2013 ? 12:11, Pierre Fenoll a ?crit : > > There, nox: https://github.com/nox/otp/compare/better-error-reports > (BTW you seem to have a mix of tabs and spaces in your code) > > > Cheers, > -- > Pierre Fenoll > > > >> On 31 October 2013 10:51, Anthony Ramine wrote: >> Even if we sent a structured term to the error logger, we would need to limit its size because the error term and stack trace is copied on the error logger heap and can be very very huge. >> >> Shameless plug: my better-error-reports (IIRC the name, can't check right now) aims first to improve stack trace formatting and second to improve the terms sent to the error logger. >> >> -- >> Anthony Ramine >> >> > Le 31 oct. 2013 ? 11:27, Matthias Lang a ?crit : >> > >> > Hi, >> > >> > TLDR: Whenever an Erlang process dies an abnormal death, there's some >> > code deep in the VM which sends an unstructured message to >> > error_logger about the death. This was surprising to me. >> > >> > >> > The Question >> > ------------ >> > >> > I was going to ask "where does this 'ERROR REPORT' message come from?": >> > >> > ~ >erl -boot start_sasl >> > Erlang R15B03 (erts-5.9.3.1)... >> > ... >> > 1> spawn(fun() -> 3 = 9 end). >> > <0.42.0> >> > 2> >> > =ERROR REPORT==== 31-Oct-2013::10:51:47 === >> > Error in process <0.42.0> with exit value: {{badmatch,9},[{erl_eval,expr,3,[]}]} >> > >> > But before asking, I dug out the answer myself. So this post is a >> > question with the answer supplied. Hope someone's interested. >> > >> > Anyway, this "Error in process <0.42.0>" message, how can that >> > possibly work? >> > >> > >> > Impossible answers >> > ------------------ >> > >> > No Erlang process is linked to <0.42.0>---I used plain spawn()---so it >> > can't work through links. >> > >> > No Erlang process is monitoring <0.42.0>, so that's out too. >> > >> > I even checked that there's no tracing on. There isn't. >> > >> > I can't find anything in the 'Barklund Draft' which says that abnormal >> > process death should give information to another process through any >> > other mechanism. So, this is a top secret part of Erlang, available >> > only to helmeted, blonde, bearded eaters of rotten fish. >> > >> > >> > The actual answer >> > ----------------- >> > >> > Deep in "beam_emu.c", there's terminate_proc(). Here's what it does: >> > >> > erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); >> > erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); >> > erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value); >> > erts_send_error_to_logger(c_p->group_leader, dsbufp); >> > >> > So, the exit value term, i.e. {badmatch, 9} and the stack trace is >> > turned into a string (!) and then sent to the process registered as >> > 'error_logger'. >> > >> > It seems OTP invaded the Erlang VM a bit... The other times I've seen >> > the VM send messages to the error logger, it's because something's on >> > fire, e.g. distribution has gone nuts. Not something mundane like a >> > process dying. Seems like a quick hack left over from long ago. >> > >> > >> > The fix >> > ------- >> > >> > If you implement your own error_logger, it's tempting to match these >> > messages so you can do things with them---you might want to format >> > them differently, or someone might have a burning need to translate >> > them to Maori---but this is unpalatable because the message comes as a >> > string. >> > >> > That leaves the approach taken by proc_lib:spawn(), which is to wrap >> > the spawned code in a 'try', which means the VM never gets its fingers >> > on that crash. And that then gets you back to what I expected: if I >> > spawn() a process, I want it to just die quietly, even if it >> > crashes. Shame that's not the default. >> > >> > Matt >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Oct 31 12:53:25 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 31 Oct 2013 12:53:25 +0100 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> <52711E67.5020605@erlang.org> <5152413E-0FEB-4073-9260-9E7C3C4B5BAC@gmail.com> Message-ID: On Thu, Oct 31, 2013 at 11:58 AM, Anthony Ramine wrote: > At least that's how I see success typing as opposed to more traditional > type systems. The original paper has the description which is precise, but from my memory: Suppose we have a function f. We notate f : A -> B as a success type iff whenever f terminates with a result of type B, then the input must have been of type A. Corollary: we can always say f : any() -> any(). Since if the function terminates with any type, then we have indeed given it any value as input. The same goes for a widening into atom() as you describe. The goal of these annotations is to look for things which are impossible. That is, we look for parameters passed to functions which does not match the inferred spec. By the definition, this leads to code which will not terminate normally and this code is often a basis for problems. It also forms the basis for "The Dialyzer is never wrong". Because if it cannot prove that the code will not terminate, it picks the conservative stance that the programmer is right. Traditional type systems pick the stance that the programmer is wrong and that the constructed term is not valid in the programming language. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu Oct 31 12:55:49 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 31 Oct 2013 12:55:49 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: References: <20131031102733.GA6528@corelatus.se> <8F3B649A-C7A8-471E-A85B-0B738E6D51B4@gmail.com> Message-ID: <1383220549.5154.12.camel@sekic1152.release> The width of a tab, counted in number of spaces, should user configurable. bengt On Thu, 2013-10-31 at 12:43 +0100, Anthony Ramine wrote: > Re: indentation: blame the Emacs mode which uses GNU style indents: X > spaces, replace any consecutive 8 spaces by a hard tab. It's quite > clever in fact but most tools (especially that damn GitHub) can't cope > with it cleanly. > > -- > Anthony Ramine > > Le 31 oct. 2013 ? 12:11, Pierre Fenoll a > ?crit : > > > > There, nox: https://github.com/nox/otp/compare/better-error-reports > > (BTW you seem to have a mix of tabs and spaces in your code) > > > > > > > > Cheers, > > -- > > Pierre Fenoll > > > > > > > > > > On 31 October 2013 10:51, Anthony Ramine wrote: > > Even if we sent a structured term to the error logger, we > > would need to limit its size because the error term and > > stack trace is copied on the error logger heap and can be > > very very huge. > > > > Shameless plug: my better-error-reports (IIRC the name, > > can't check right now) aims first to improve stack trace > > formatting and second to improve the terms sent to the error > > logger. > > > > -- > > Anthony Ramine > > > > > Le 31 oct. 2013 ? 11:27, Matthias Lang > > a ?crit : > > > > > > Hi, > > > > > > TLDR: Whenever an Erlang process dies an abnormal death, > > there's some > > > code deep in the VM which sends an unstructured > > message to > > > error_logger about the death. This was surprising to > > me. > > > > > > > > > The Question > > > ------------ > > > > > > I was going to ask "where does this 'ERROR REPORT' message > > come from?": > > > > > > ~ >erl -boot start_sasl > > > Erlang R15B03 (erts-5.9.3.1)... > > > ... > > > 1> spawn(fun() -> 3 = 9 end). > > > <0.42.0> > > > 2> > > > =ERROR REPORT==== 31-Oct-2013::10:51:47 === > > > Error in process <0.42.0> with exit value: > > {{badmatch,9},[{erl_eval,expr,3,[]}]} > > > > > > But before asking, I dug out the answer myself. So this > > post is a > > > question with the answer supplied. Hope someone's > > interested. > > > > > > Anyway, this "Error in process <0.42.0>" message, how can > > that > > > possibly work? > > > > > > > > > Impossible answers > > > ------------------ > > > > > > No Erlang process is linked to <0.42.0>---I used plain > > spawn()---so it > > > can't work through links. > > > > > > No Erlang process is monitoring <0.42.0>, so that's out > > too. > > > > > > I even checked that there's no tracing on. There isn't. > > > > > > I can't find anything in the 'Barklund Draft' which says > > that abnormal > > > process death should give information to another process > > through any > > > other mechanism. So, this is a top secret part of Erlang, > > available > > > only to helmeted, blonde, bearded eaters of rotten fish. > > > > > > > > > The actual answer > > > ----------------- > > > > > > Deep in "beam_emu.c", there's terminate_proc(). Here's > > what it does: > > > > > > erts_dsprintf_buf_t *dsbufp = > > erts_create_logger_dsbuf(); > > > erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); > > > erts_dsprintf(dsbufp,"with exit value: %0.*T\n", > > display_items, Value); > > > erts_send_error_to_logger(c_p->group_leader, dsbufp); > > > > > > So, the exit value term, i.e. {badmatch, 9} and the stack > > trace is > > > turned into a string (!) and then sent to the process > > registered as > > > 'error_logger'. > > > > > > It seems OTP invaded the Erlang VM a bit... The other > > times I've seen > > > the VM send messages to the error logger, it's because > > something's on > > > fire, e.g. distribution has gone nuts. Not something > > mundane like a > > > process dying. Seems like a quick hack left over from long > > ago. > > > > > > > > > The fix > > > ------- > > > > > > If you implement your own error_logger, it's tempting to > > match these > > > messages so you can do things with them---you might want > > to format > > > them differently, or someone might have a burning need to > > translate > > > them to Maori---but this is unpalatable because the > > message comes as a > > > string. > > > > > > That leaves the approach taken by proc_lib:spawn(), which > > is to wrap > > > the spawned code in a 'try', which means the VM never gets > > its fingers > > > on that crash. And that then gets you back to what I > > expected: if I > > > spawn() a process, I want it to just die quietly, even if > > it > > > crashes. Shame that's not the default. > > > > > > Matt > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Thu Oct 31 12:58:09 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 31 Oct 2013 12:58:09 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <1383220549.5154.12.camel@sekic1152.release> References: <20131031102733.GA6528@corelatus.se> <8F3B649A-C7A8-471E-A85B-0B738E6D51B4@gmail.com> <1383220549.5154.12.camel@sekic1152.release> Message-ID: <18821619-37CE-471A-A152-D1B5FD59F7A4@gmail.com> Are we really going to debate this? I don?t want to, but I also don?t want to read people stating their opinion as if they were facts. -- Anthony Ramine Le 31 oct. 2013 ? 12:55, Bengt Kleberg a ?crit : > The width of a tab, counted in number of spaces, should user > configurable. > > > bengt > > On Thu, 2013-10-31 at 12:43 +0100, Anthony Ramine wrote: >> Re: indentation: blame the Emacs mode which uses GNU style indents: X >> spaces, replace any consecutive 8 spaces by a hard tab. It's quite >> clever in fact but most tools (especially that damn GitHub) can't cope >> with it cleanly. >> >> -- >> Anthony Ramine >> >> Le 31 oct. 2013 ? 12:11, Pierre Fenoll a >> ?crit : >> >> >>> There, nox: https://github.com/nox/otp/compare/better-error-reports >>> (BTW you seem to have a mix of tabs and spaces in your code) >>> >>> >>> >>> Cheers, >>> -- >>> Pierre Fenoll >>> >>> >>> >>> >>> On 31 October 2013 10:51, Anthony Ramine wrote: >>> Even if we sent a structured term to the error logger, we >>> would need to limit its size because the error term and >>> stack trace is copied on the error logger heap and can be >>> very very huge. >>> >>> Shameless plug: my better-error-reports (IIRC the name, >>> can't check right now) aims first to improve stack trace >>> formatting and second to improve the terms sent to the error >>> logger. >>> >>> -- >>> Anthony Ramine >>> >>>> Le 31 oct. 2013 ? 11:27, Matthias Lang >>> a ?crit : >>>> >>>> Hi, >>>> >>>> TLDR: Whenever an Erlang process dies an abnormal death, >>> there's some >>>> code deep in the VM which sends an unstructured >>> message to >>>> error_logger about the death. This was surprising to >>> me. >>>> >>>> >>>> The Question >>>> ------------ >>>> >>>> I was going to ask "where does this 'ERROR REPORT' message >>> come from?": >>>> >>>> ~ >erl -boot start_sasl >>>> Erlang R15B03 (erts-5.9.3.1)... >>>> ... >>>> 1> spawn(fun() -> 3 = 9 end). >>>> <0.42.0> >>>> 2> >>>> =ERROR REPORT==== 31-Oct-2013::10:51:47 === >>>> Error in process <0.42.0> with exit value: >>> {{badmatch,9},[{erl_eval,expr,3,[]}]} >>>> >>>> But before asking, I dug out the answer myself. So this >>> post is a >>>> question with the answer supplied. Hope someone's >>> interested. >>>> >>>> Anyway, this "Error in process <0.42.0>" message, how can >>> that >>>> possibly work? >>>> >>>> >>>> Impossible answers >>>> ------------------ >>>> >>>> No Erlang process is linked to <0.42.0>---I used plain >>> spawn()---so it >>>> can't work through links. >>>> >>>> No Erlang process is monitoring <0.42.0>, so that's out >>> too. >>>> >>>> I even checked that there's no tracing on. There isn't. >>>> >>>> I can't find anything in the 'Barklund Draft' which says >>> that abnormal >>>> process death should give information to another process >>> through any >>>> other mechanism. So, this is a top secret part of Erlang, >>> available >>>> only to helmeted, blonde, bearded eaters of rotten fish. >>>> >>>> >>>> The actual answer >>>> ----------------- >>>> >>>> Deep in "beam_emu.c", there's terminate_proc(). Here's >>> what it does: >>>> >>>> erts_dsprintf_buf_t *dsbufp = >>> erts_create_logger_dsbuf(); >>>> erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); >>>> erts_dsprintf(dsbufp,"with exit value: %0.*T\n", >>> display_items, Value); >>>> erts_send_error_to_logger(c_p->group_leader, dsbufp); >>>> >>>> So, the exit value term, i.e. {badmatch, 9} and the stack >>> trace is >>>> turned into a string (!) and then sent to the process >>> registered as >>>> 'error_logger'. >>>> >>>> It seems OTP invaded the Erlang VM a bit... The other >>> times I've seen >>>> the VM send messages to the error logger, it's because >>> something's on >>>> fire, e.g. distribution has gone nuts. Not something >>> mundane like a >>>> process dying. Seems like a quick hack left over from long >>> ago. >>>> >>>> >>>> The fix >>>> ------- >>>> >>>> If you implement your own error_logger, it's tempting to >>> match these >>>> messages so you can do things with them---you might want >>> to format >>>> them differently, or someone might have a burning need to >>> translate >>>> them to Maori---but this is unpalatable because the >>> message comes as a >>>> string. >>>> >>>> That leaves the approach taken by proc_lib:spawn(), which >>> is to wrap >>>> the spawned code in a 'try', which means the VM never gets >>> its fingers >>>> on that crash. And that then gets you back to what I >>> expected: if I >>>> spawn() a process, I want it to just die quietly, even if >>> it >>>> crashes. Shame that's not the default. >>>> >>>> Matt >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From carlsson.richard@REDACTED Thu Oct 31 13:02:17 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 31 Oct 2013 13:02:17 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <20131031102733.GA6528@corelatus.se> References: <20131031102733.GA6528@corelatus.se> Message-ID: <527246C9.1080403@gmail.com> Yes, when a process terminates abnormally (including uncaught throw/1, but not when terminating due to exit/1), a message is sent to the error logger. This was never described in the Barklund draft (very few people knew that anything special happened in that situation), but I discovered it when I was working on exceptions - see the end of section 2.7 in http://www.erlang.se/workshop/2004/exception.pdf, and it affected how the final try/catch construction and the classification of exceptions had to work. We also took the opportunity to describe this behaviour in section 2.8 of "Erlang and OTP in Action". I can't find anything about it anywhere in the OTP docs. On a language specification level, it's pretty unfortunate that OTP made this hard connection between something as basic as exceptions and a high-level feature like the error logger. And as you observed, the format it's being sent on is not good either. I'm not sure if that can be changed or if it needs to remain backwards compatible with existing code out there. /Richard On 2013-10-31 11:27 , Matthias Lang wrote: > Hi, > > TLDR: Whenever an Erlang process dies an abnormal death, there's some > code deep in the VM which sends an unstructured message to > error_logger about the death. This was surprising to me. > > > The Question > ------------ > > I was going to ask "where does this 'ERROR REPORT' message come from?": > > ~ >erl -boot start_sasl > Erlang R15B03 (erts-5.9.3.1)... > ... > 1> spawn(fun() -> 3 = 9 end). > <0.42.0> > 2> > =ERROR REPORT==== 31-Oct-2013::10:51:47 === > Error in process <0.42.0> with exit value: {{badmatch,9},[{erl_eval,expr,3,[]}]} > > But before asking, I dug out the answer myself. So this post is a > question with the answer supplied. Hope someone's interested. > > Anyway, this "Error in process <0.42.0>" message, how can that > possibly work? > > > Impossible answers > ------------------ > > No Erlang process is linked to <0.42.0>---I used plain spawn()---so it > can't work through links. > > No Erlang process is monitoring <0.42.0>, so that's out too. > > I even checked that there's no tracing on. There isn't. > > I can't find anything in the 'Barklund Draft' which says that abnormal > process death should give information to another process through any > other mechanism. So, this is a top secret part of Erlang, available > only to helmeted, blonde, bearded eaters of rotten fish. > > > The actual answer > ----------------- > > Deep in "beam_emu.c", there's terminate_proc(). Here's what it does: > > erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); > erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); > erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value); > erts_send_error_to_logger(c_p->group_leader, dsbufp); > > So, the exit value term, i.e. {badmatch, 9} and the stack trace is > turned into a string (!) and then sent to the process registered as > 'error_logger'. > > It seems OTP invaded the Erlang VM a bit... The other times I've seen > the VM send messages to the error logger, it's because something's on > fire, e.g. distribution has gone nuts. Not something mundane like a > process dying. Seems like a quick hack left over from long ago. > > > The fix > ------- > > If you implement your own error_logger, it's tempting to match these > messages so you can do things with them---you might want to format > them differently, or someone might have a burning need to translate > them to Maori---but this is unpalatable because the message comes as a > string. > > That leaves the approach taken by proc_lib:spawn(), which is to wrap > the spawned code in a 'try', which means the VM never gets its fingers > on that crash. And that then gets you back to what I expected: if I > spawn() a process, I want it to just die quietly, even if it > crashes. Shame that's not the default. > > Matt > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bengt.kleberg@REDACTED Thu Oct 31 13:13:11 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 31 Oct 2013 13:13:11 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <18821619-37CE-471A-A152-D1B5FD59F7A4@gmail.com> References: <20131031102733.GA6528@corelatus.se> <8F3B649A-C7A8-471E-A85B-0B738E6D51B4@gmail.com> <1383220549.5154.12.camel@sekic1152.release> <18821619-37CE-471A-A152-D1B5FD59F7A4@gmail.com> Message-ID: <1383221591.5154.13.camel@sekic1152.release> No debate. Just stating an opinion as a fact. bengt On Thu, 2013-10-31 at 12:58 +0100, Anthony Ramine wrote: > Are we really going to debate this? > > I don?t want to, but I also don?t want to read people stating their opinion as if they were facts. > > -- > Anthony Ramine > > Le 31 oct. 2013 ? 12:55, Bengt Kleberg a ?crit : > > > The width of a tab, counted in number of spaces, should user > > configurable. > > > > > > bengt > > > > On Thu, 2013-10-31 at 12:43 +0100, Anthony Ramine wrote: > >> Re: indentation: blame the Emacs mode which uses GNU style indents: X > >> spaces, replace any consecutive 8 spaces by a hard tab. It's quite > >> clever in fact but most tools (especially that damn GitHub) can't cope > >> with it cleanly. > >> > >> -- > >> Anthony Ramine > >> > >> Le 31 oct. 2013 ? 12:11, Pierre Fenoll a > >> ?crit : > >> > >> > >>> There, nox: https://github.com/nox/otp/compare/better-error-reports > >>> (BTW you seem to have a mix of tabs and spaces in your code) > >>> > >>> > >>> > >>> Cheers, > >>> -- > >>> Pierre Fenoll > >>> > >>> > >>> > >>> > >>> On 31 October 2013 10:51, Anthony Ramine wrote: > >>> Even if we sent a structured term to the error logger, we > >>> would need to limit its size because the error term and > >>> stack trace is copied on the error logger heap and can be > >>> very very huge. > >>> > >>> Shameless plug: my better-error-reports (IIRC the name, > >>> can't check right now) aims first to improve stack trace > >>> formatting and second to improve the terms sent to the error > >>> logger. > >>> > >>> -- > >>> Anthony Ramine > >>> > >>>> Le 31 oct. 2013 ? 11:27, Matthias Lang > >>> a ?crit : > >>>> > >>>> Hi, > >>>> > >>>> TLDR: Whenever an Erlang process dies an abnormal death, > >>> there's some > >>>> code deep in the VM which sends an unstructured > >>> message to > >>>> error_logger about the death. This was surprising to > >>> me. > >>>> > >>>> > >>>> The Question > >>>> ------------ > >>>> > >>>> I was going to ask "where does this 'ERROR REPORT' message > >>> come from?": > >>>> > >>>> ~ >erl -boot start_sasl > >>>> Erlang R15B03 (erts-5.9.3.1)... > >>>> ... > >>>> 1> spawn(fun() -> 3 = 9 end). > >>>> <0.42.0> > >>>> 2> > >>>> =ERROR REPORT==== 31-Oct-2013::10:51:47 === > >>>> Error in process <0.42.0> with exit value: > >>> {{badmatch,9},[{erl_eval,expr,3,[]}]} > >>>> > >>>> But before asking, I dug out the answer myself. So this > >>> post is a > >>>> question with the answer supplied. Hope someone's > >>> interested. > >>>> > >>>> Anyway, this "Error in process <0.42.0>" message, how can > >>> that > >>>> possibly work? > >>>> > >>>> > >>>> Impossible answers > >>>> ------------------ > >>>> > >>>> No Erlang process is linked to <0.42.0>---I used plain > >>> spawn()---so it > >>>> can't work through links. > >>>> > >>>> No Erlang process is monitoring <0.42.0>, so that's out > >>> too. > >>>> > >>>> I even checked that there's no tracing on. There isn't. > >>>> > >>>> I can't find anything in the 'Barklund Draft' which says > >>> that abnormal > >>>> process death should give information to another process > >>> through any > >>>> other mechanism. So, this is a top secret part of Erlang, > >>> available > >>>> only to helmeted, blonde, bearded eaters of rotten fish. > >>>> > >>>> > >>>> The actual answer > >>>> ----------------- > >>>> > >>>> Deep in "beam_emu.c", there's terminate_proc(). Here's > >>> what it does: > >>>> > >>>> erts_dsprintf_buf_t *dsbufp = > >>> erts_create_logger_dsbuf(); > >>>> erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); > >>>> erts_dsprintf(dsbufp,"with exit value: %0.*T\n", > >>> display_items, Value); > >>>> erts_send_error_to_logger(c_p->group_leader, dsbufp); > >>>> > >>>> So, the exit value term, i.e. {badmatch, 9} and the stack > >>> trace is > >>>> turned into a string (!) and then sent to the process > >>> registered as > >>>> 'error_logger'. > >>>> > >>>> It seems OTP invaded the Erlang VM a bit... The other > >>> times I've seen > >>>> the VM send messages to the error logger, it's because > >>> something's on > >>>> fire, e.g. distribution has gone nuts. Not something > >>> mundane like a > >>>> process dying. Seems like a quick hack left over from long > >>> ago. > >>>> > >>>> > >>>> The fix > >>>> ------- > >>>> > >>>> If you implement your own error_logger, it's tempting to > >>> match these > >>>> messages so you can do things with them---you might want > >>> to format > >>>> them differently, or someone might have a burning need to > >>> translate > >>>> them to Maori---but this is unpalatable because the > >>> message comes as a > >>>> string. > >>>> > >>>> That leaves the approach taken by proc_lib:spawn(), which > >>> is to wrap > >>>> the spawned code in a 'try', which means the VM never gets > >>> its fingers > >>>> on that crash. And that then gets you back to what I > >>> expected: if I > >>>> spawn() a process, I want it to just die quietly, even if > >>> it > >>>> crashes. Shame that's not the default. > >>>> > >>>> Matt > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >>> > >>> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > From n.oxyde@REDACTED Thu Oct 31 13:14:42 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 31 Oct 2013 13:14:42 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <527246C9.1080403@gmail.com> References: <20131031102733.GA6528@corelatus.se> <527246C9.1080403@gmail.com> Message-ID: <21B593BD-8FB5-4E50-BECB-FB286D0E64CD@gmail.com> There is a way: https://github.com/erlang/otp/blob/77bf7dfa0cc6d99c426d4057da8446dc51cea7aa/erts/emulator/beam/utils.c#L1648-1651 You can see in this code comment that what is actually sent is a format string and a list of args. We could add textual parts to the trivial "~s~n" format string and make the list of arguments more structured. To handle the truncation of stack traces, I would use a first ref() argument which is ignored at the start of the format string and use that ref to identify "holes" in the copied terms, i.e. put that reference when copying where ?...? would have been printed previously. Clever depth arguments would make io continue to print ??? where these references will occur. -- Anthony Ramine Le 31 oct. 2013 ? 13:02, Richard Carlsson a ?crit : > I'm not sure if that can be changed or if it needs to remain backwards compatible with existing code out there. From colanderman@REDACTED Thu Oct 31 14:07:53 2013 From: colanderman@REDACTED (Chris King) Date: Thu, 31 Oct 2013 09:07:53 -0400 Subject: [erlang-questions] Maps branch and disclaimers In-Reply-To: References: <526A9E59.7090406@erlang.org> <113390727.348961.1382975327245.JavaMail.zimbra@erlang-solutions.com> <1921693339.393635.1383136844311.JavaMail.zimbra@erlang-solutions.com> <52710EDF.6010103@erlang.org> <52711694.9090500@erlang.org> <52711E67.5020605@erlang.org> <5152413E-0FEB-4073-9260-9E7C3C4B5BAC@gmail.com> Message-ID: On Thu, 31 Oct 2013 06:58:18 -0400, Anthony Ramine wrote: > Write an unary function with 15 (might need more) different clauses > f(a1) -> ...; ...; f(a15) -> .... > > Dialyzer will infer atom() for the argument type because large type > unions are broadened to make the various type unifications happen in a > reasonable time, if I understand this correctly. Yes, Dialyzer necessarily approximates types. And it, by design, fails on the false negative side of things: it can infer that functions accept types which actually make them crash. This has no bearing on the *actual* type signature written by a human to communicate to other humans. These have meaning outside of Dialyzer. Unfortunately without a semantic definition of these signatures (which I sadly can't find!) we're both grasping at straws. The fact that Dialyzer is *able* (with -Wunderspecs) to warn that a type is too broad tells me at least that the semantics of type signatures is ambiguous. Whether this option is a "here's a more sound analysis we're working on" option, or a "this is for weird people who insist that types imply success" is unclear. From robert.virding@REDACTED Thu Oct 31 16:12:17 2013 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 31 Oct 2013 16:12:17 +0100 (CET) Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <527246C9.1080403@gmail.com> References: <20131031102733.GA6528@corelatus.se> <527246C9.1080403@gmail.com> Message-ID: <334467983.529030.1383232337055.JavaMail.zimbra@erlang-solutions.com> What a stupid thing for the system to do! Erlang is Erlang and OTP is something on top of Erlang. It was never written into the spec because we didn't know about it. How can we get rid of it? It is definitely a bug, at best a bad design decision! Robert ----- Original Message ----- > From: "Richard Carlsson" > > Yes, when a process terminates abnormally (including uncaught throw/1, > but not when terminating due to exit/1), a message is sent to the error > logger. This was never described in the Barklund draft (very few people > knew that anything special happened in that situation), but I discovered > it when I was working on exceptions - see the end of section 2.7 in > http://www.erlang.se/workshop/2004/exception.pdf, and it affected how > the final try/catch construction and the classification of exceptions > had to work. We also took the opportunity to describe this behaviour in > section 2.8 of "Erlang and OTP in Action". I can't find anything about > it anywhere in the OTP docs. > > On a language specification level, it's pretty unfortunate that OTP made > this hard connection between something as basic as exceptions and a > high-level feature like the error logger. And as you observed, the > format it's being sent on is not good either. I'm not sure if that can > be changed or if it needs to remain backwards compatible with existing > code out there. > > /Richard > > > On 2013-10-31 11:27 , Matthias Lang wrote: > > Hi, > > > > TLDR: Whenever an Erlang process dies an abnormal death, there's some > > code deep in the VM which sends an unstructured message to > > error_logger about the death. This was surprising to me. > > > > > > The Question > > ------------ > > > > I was going to ask "where does this 'ERROR REPORT' message come from?": > > > > ~ >erl -boot start_sasl > > Erlang R15B03 (erts-5.9.3.1)... > > ... > > 1> spawn(fun() -> 3 = 9 end). > > <0.42.0> > > 2> > > =ERROR REPORT==== 31-Oct-2013::10:51:47 === > > Error in process <0.42.0> with exit value: > > {{badmatch,9},[{erl_eval,expr,3,[]}]} > > > > But before asking, I dug out the answer myself. So this post is a > > question with the answer supplied. Hope someone's interested. > > > > Anyway, this "Error in process <0.42.0>" message, how can that > > possibly work? > > > > > > Impossible answers > > ------------------ > > > > No Erlang process is linked to <0.42.0>---I used plain spawn()---so it > > can't work through links. > > > > No Erlang process is monitoring <0.42.0>, so that's out too. > > > > I even checked that there's no tracing on. There isn't. > > > > I can't find anything in the 'Barklund Draft' which says that abnormal > > process death should give information to another process through any > > other mechanism. So, this is a top secret part of Erlang, available > > only to helmeted, blonde, bearded eaters of rotten fish. > > > > > > The actual answer > > ----------------- > > > > Deep in "beam_emu.c", there's terminate_proc(). Here's what it does: > > > > erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf(); > > erts_dsprintf(dsbufp, "Error in process %T ", c_p->id); > > erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value); > > erts_send_error_to_logger(c_p->group_leader, dsbufp); > > > > So, the exit value term, i.e. {badmatch, 9} and the stack trace is > > turned into a string (!) and then sent to the process registered as > > 'error_logger'. > > > > It seems OTP invaded the Erlang VM a bit... The other times I've seen > > the VM send messages to the error logger, it's because something's on > > fire, e.g. distribution has gone nuts. Not something mundane like a > > process dying. Seems like a quick hack left over from long ago. > > > > > > The fix > > ------- > > > > If you implement your own error_logger, it's tempting to match these > > messages so you can do things with them---you might want to format > > them differently, or someone might have a burning need to translate > > them to Maori---but this is unpalatable because the message comes as a > > string. > > > > That leaves the approach taken by proc_lib:spawn(), which is to wrap > > the spawned code in a 'try', which means the VM never gets its fingers > > on that crash. And that then gets you back to what I expected: if I > > spawn() a process, I want it to just die quietly, even if it > > crashes. Shame that's not the default. > > > > Matt > > _______________________________________________ > > 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 n.oxyde@REDACTED Thu Oct 31 16:25:47 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 31 Oct 2013 16:25:47 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <334467983.529030.1383232337055.JavaMail.zimbra@erlang-solutions.com> References: <20131031102733.GA6528@corelatus.se> <527246C9.1080403@gmail.com> <334467983.529030.1383232337055.JavaMail.zimbra@erlang-solutions.com> Message-ID: Would you get rid of error_handler too? Because I find that worse than the error_logger situation. At least a logger is just a logger, it can?t masquerade a function call as another one or do fancy things like this. -- Anthony Ramine Le 31 oct. 2013 ? 16:12, Robert Virding a ?crit : > What a stupid thing for the system to do! Erlang is Erlang and OTP is something on top of Erlang. It was never written into the spec because we didn't know about it. How can we get rid of it? It is definitely a bug, at best a bad design decision! From matthias@REDACTED Thu Oct 31 17:15:39 2013 From: matthias@REDACTED (Matthias Lang) Date: Thu, 31 Oct 2013 17:15:39 +0100 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <334467983.529030.1383232337055.JavaMail.zimbra@erlang-solutions.com> References: <20131031102733.GA6528@corelatus.se> <527246C9.1080403@gmail.com> <334467983.529030.1383232337055.JavaMail.zimbra@erlang-solutions.com> Message-ID: <20131031161539.GA15348@corelatus.se> Hi, RC> I'm not sure if that can RC be changed or if it needs to remain RC> backwards compatible with existing code out there. I think it would affect people, but not code. People might use the 'process X crashed...' message as part of their development workflow, to see problems while hacking. I doubt removing it would affect code. The only thing it's likely to affect is logging code, and logging code won't care if there's less to log. The least farfetched idea I can come up with for useful code that would be affected is if someone clever has built a "supervisor-less" supervision system based on parsing those messages. Matthias From max.lapshin@REDACTED Thu Oct 31 17:21:53 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 31 Oct 2013 20:21:53 +0400 Subject: [erlang-questions] An answer: how does SASL know that a process died? In-Reply-To: <20131031161539.GA15348@corelatus.se> References: <20131031102733.GA6528@corelatus.se> <527246C9.1080403@gmail.com> <334467983.529030.1383232337055.JavaMail.zimbra@erlang-solutions.com> <20131031161539.GA15348@corelatus.se> Message-ID: Dumping reason of failure to string can take up to 20 GB of memory and many hours of useless work. I've seen it many times. Thus reporting errors must always be done in erlang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.elsgaard@REDACTED Thu Oct 31 21:08:18 2013 From: thomas.elsgaard@REDACTED (Thomas Elsgaard) Date: Thu, 31 Oct 2013 17:08:18 -0300 Subject: [erlang-questions] emysql Message-ID: Hi list How can i easiest replace 'baz' with content from an variable ? emysql:execute(hello_pool, <<"UPDATE hello_table SET hello_text = 'baz'">>) Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.boudeville@REDACTED Thu Oct 31 21:51:11 2013 From: olivier.boudeville@REDACTED (Olivier Boudeville) Date: Thu, 31 Oct 2013 21:51:11 +0100 Subject: [erlang-questions] Arch Linux patches? Message-ID: <5272C2BF.5050808@online.fr> Hi, I may be wrong but I think that, some time ago, someone (maybe Lo?c?) mentioned incidentally in this mailing list that the Arch Linux version of Erlang (obtained through pacman) was reported to be, at least in some cases, significantly more efficient than the stock, official version (the trouble is that I can't find that message from the list archives). I was wondering if it had been confirmed, and, if yes, if there were some patches sent upstream by the Arch maintainers that could be fruitfully applied to the official sources? Thanks for any information! Cheers, Olivier. From dmkolesnikov@REDACTED Thu Oct 31 22:06:31 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 31 Oct 2013 23:06:31 +0200 Subject: [erlang-questions] Arch Linux patches? In-Reply-To: <5272C2BF.5050808@online.fr> References: <5272C2BF.5050808@online.fr> Message-ID: Hello, Here is reference to mail thread http://erlang.org/pipermail/erlang-questions/2013-September/075313.html - Dmitry On Oct 31, 2013, at 10:51 PM, Olivier Boudeville wrote: > Hi, > > I may be wrong but I think that, some time ago, someone (maybe Lo?c?) mentioned incidentally in this mailing list that the Arch Linux version of Erlang (obtained through pacman) was reported to be, at least in some cases, significantly more efficient than the stock, official version (the trouble is that I can't find that message from the list archives). > > I was wondering if it had been confirmed, and, if yes, if there were some patches sent upstream by the Arch maintainers that could be fruitfully applied to the official sources? > > Thanks for any information! > > Cheers, > > Olivier. > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From aaron.l.france@REDACTED Thu Oct 31 22:04:26 2013 From: aaron.l.france@REDACTED (Aaron France) Date: Thu, 31 Oct 2013 22:04:26 +0100 Subject: [erlang-questions] Arch Linux patches? In-Reply-To: <5272C2BF.5050808@online.fr> References: <5272C2BF.5050808@online.fr> Message-ID: Demonstrably false. ArchLinux uses https://gist.github.com/AeroNotix/7257133 this to build it's package, no patches, no wicked switches, just a plain makefile. Aaron On Thu, Oct 31, 2013 at 9:51 PM, Olivier Boudeville < olivier.boudeville@REDACTED> wrote: > Hi, > > I may be wrong but I think that, some time ago, someone (maybe Lo?c?) > mentioned incidentally in this mailing list that the Arch Linux version of > Erlang (obtained through pacman) was reported to be, at least in some > cases, significantly more efficient than the stock, official version (the > trouble is that I can't find that message from the list archives). > > I was wondering if it had been confirmed, and, if yes, if there were some > patches sent upstream by the Arch maintainers that could be fruitfully > applied to the official sources? > > Thanks for any information! > > Cheers, > > Olivier. > > > > > > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Thu Oct 31 22:16:57 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 31 Oct 2013 23:16:57 +0200 Subject: [erlang-questions] emysql In-Reply-To: References: Message-ID: <31204C3A-9188-400C-A71F-A12B6B86C01C@gmail.com> Hello, You can take a look to my template library https://github.com/fogfish/swirl Here is quick code snippet swirl:c(my_query, "UPDATE hello_table SET hello_text = '{baz}'"). my_query:render([{baz, "my text"}]). Output: "UPDATE hello_table SET hello_text = 'my text'" Best Regards, Dmitry On Oct 31, 2013, at 10:08 PM, Thomas Elsgaard wrote: > Hi list > > How can i easiest replace 'baz' with content from an variable ? > > emysql:execute(hello_pool, <<"UPDATE hello_table SET hello_text = 'baz'">>) > > Thomas > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From manprog@REDACTED Thu Oct 31 22:21:45 2013 From: manprog@REDACTED (Bernardo Alvez) Date: Thu, 31 Oct 2013 19:21:45 -0200 Subject: [erlang-questions] emysql In-Reply-To: <31204C3A-9188-400C-A71F-A12B6B86C01C@gmail.com> References: <31204C3A-9188-400C-A71F-A12B6B86C01C@gmail.com> Message-ID: <5272C9E9.6080803@adinet.com.uy> Hi Thomas, Why not? Baz = <<"some_text">>, emysql:execute(hello_pool,<<"UPDATE hello_table SET hello_text = '", Baz/binary, "'">>). Best regards Dmitry Kolesnikov escribi?: > Hello, > > You can take a look to my template library > https://github.com/fogfish/swirl > > Here is quick code snippet > > swirl:c(my_query, "UPDATE hello_table SET hello_text = '{baz}'"). > my_query:render([{baz, "my text"}]). > > Output: > > "UPDATE hello_table SET hello_text = 'my text'" > > Best Regards, > Dmitry > > On Oct 31, 2013, at 10:08 PM, Thomas Elsgaard wrote: > >> Hi list >> >> How can i easiest replace 'baz' with content from an variable ? >> >> emysql:execute(hello_pool, <<"UPDATE hello_table SET hello_text = 'baz'">>) >> >> Thomas >> _______________________________________________ >> 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 essen@REDACTED Thu Oct 31 22:22:52 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 31 Oct 2013 22:22:52 +0100 Subject: [erlang-questions] Arch Linux patches? In-Reply-To: References: <5272C2BF.5050808@online.fr> Message-ID: <5272CA2C.1050908@ninenines.eu> I know the Makefile doesn't seem to do anything but last I checked (been a while) I had better performance with the precompiled version compared to compiling with kerl (I'm not sure if I tried with manual compilation). I'll check again tomorrow. On 10/31/2013 10:04 PM, Aaron France wrote: > Demonstrably false. > > ArchLinux uses https://gist.github.com/AeroNotix/7257133 this to build > it's package, no patches, no wicked switches, just a plain makefile. > > Aaron > > > On Thu, Oct 31, 2013 at 9:51 PM, Olivier Boudeville > > wrote: > > Hi, > > I may be wrong but I think that, some time ago, someone (maybe > Lo?c?) mentioned incidentally in this mailing list that the Arch > Linux version of Erlang (obtained through pacman) was reported to > be, at least in some cases, significantly more efficient than the > stock, official version (the trouble is that I can't find that > message from the list archives). > > I was wondering if it had been confirmed, and, if yes, if there were > some patches sent upstream by the Arch maintainers that could be > fruitfully applied to the official sources? > > Thanks for any information! > > Cheers, > > Olivier. > > > > > > _________________________________________________ > 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 Erlang Cowboy Nine Nines http://ninenines.eu From marc@REDACTED Thu Oct 31 22:36:16 2013 From: marc@REDACTED (marc@REDACTED) Date: Thu, 31 Oct 2013 17:36:16 -0400 Subject: [erlang-questions] emysql In-Reply-To: <5272C9E9.6080803@adinet.com.uy> References: <31204C3A-9188-400C-A71F-A12B6B86C01C@gmail.com> <5272C9E9.6080803@adinet.com.uy> Message-ID: <20131031213616.50819218.64751.2998@opscode.com> An HTML attachment was scrubbed... URL: From aaron.l.france@REDACTED Thu Oct 31 22:40:06 2013 From: aaron.l.france@REDACTED (Aaron France) Date: Thu, 31 Oct 2013 22:40:06 +0100 Subject: [erlang-questions] Arch Linux patches? In-Reply-To: <5272CA2C.1050908@ninenines.eu> References: <5272C2BF.5050808@online.fr> <5272CA2C.1050908@ninenines.eu> Message-ID: Any tests I can run locally would be more than welcome. Arch is a great distro to run, I just don't want mistruths being spread. On Thu, Oct 31, 2013 at 10:22 PM, Lo?c Hoguin wrote: > I know the Makefile doesn't seem to do anything but last I checked (been a > while) I had better performance with the precompiled version compared to > compiling with kerl (I'm not sure if I tried with manual compilation). > > I'll check again tomorrow. > > > On 10/31/2013 10:04 PM, Aaron France wrote: > >> Demonstrably false. >> >> ArchLinux uses https://gist.github.com/**AeroNotix/7257133this to build >> it's package, no patches, no wicked switches, just a plain makefile. >> >> Aaron >> >> >> On Thu, Oct 31, 2013 at 9:51 PM, Olivier Boudeville >> >> >> wrote: >> >> Hi, >> >> I may be wrong but I think that, some time ago, someone (maybe >> Lo?c?) mentioned incidentally in this mailing list that the Arch >> >> Linux version of Erlang (obtained through pacman) was reported to >> be, at least in some cases, significantly more efficient than the >> stock, official version (the trouble is that I can't find that >> message from the list archives). >> >> I was wondering if it had been confirmed, and, if yes, if there were >> some patches sent upstream by the Arch maintainers that could be >> fruitfully applied to the official sources? >> >> Thanks for any information! >> >> Cheers, >> >> Olivier. >> >> >> >> >> >> ______________________________**___________________ >> 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 > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Thu Oct 31 22:55:32 2013 From: freza@REDACTED (Jachym Holecek) Date: Thu, 31 Oct 2013 17:55:32 -0400 Subject: [erlang-questions] emysql In-Reply-To: <5272C9E9.6080803@adinet.com.uy> References: <31204C3A-9188-400C-A71F-A12B6B86C01C@gmail.com> <5272C9E9.6080803@adinet.com.uy> Message-ID: <20131031215532.GA18946@circlewave.net> # Bernardo Alvez 2013-10-31: > Hi Thomas, > > Why not? > > Baz = <<"some_text">>, > emysql:execute(hello_pool,<<"UPDATE hello_table SET hello_text = '", > Baz/binary, "'">>). http://xkcd.com/327/ BR, -- Jachym