From serge@REDACTED Thu Sep 1 00:17:26 2016 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 31 Aug 2016 18:17:26 -0400 Subject: [erlang-questions] Why do "interface to language X" projects all seem to die out? In-Reply-To: <20160831141806.uviuy6ix3ldolhip@corelatus.se> References: <20160831141806.uviuy6ix3ldolhip@corelatus.se> Message-ID: Here's another C++/Erlang interface that has some on-going activity: https://github.com/saleyn/eixx As I see it if the author is involved in some work that uses such project, the project is alive, otherwise the community is not that large to get involved and learn new APIs. On Wed, Aug 31, 2016 at 10:18 AM, Matthias Lang wrote: > Hi, > > Pretty much all of the "not built in to OTP" ways to connect to other > languages seem to have died, i.e. > > - EPI (C++). Last commit 2009. > - py_interface (Python). Last commit 2014. Freshest of the lot. > - edtk (C). Last release 2007. > - dryverl (C). Last release 2008. > - erlua (Lua). Project page dead. Author's email is dead. > - erlualib (last commit 2010). Github-linked company page dead. > > Can anyone offer some experiences or ideas why? > > Could it be that these types of solutions are rarely needed? Maybe > NIFs are unbeatable for the "narrow interface, no state, high > performance" cases and port programs with hand-rolled interfaces most > of the rest. > > Matt > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dleach@REDACTED Thu Sep 1 01:22:00 2016 From: dleach@REDACTED (David Leach) Date: Wed, 31 Aug 2016 23:22:00 +0000 Subject: [erlang-questions] Why do "interface to language X" projects all seem to die out? In-Reply-To: References: <20160831141806.uviuy6ix3ldolhip@corelatus.se> <57C726B9.7000303@gmail.com>, Message-ID: We use erlport in production quite successfully, although we'd also like the map feature we haven't had any major issues with it. So although there may be little activity it does what it says it does. ________________________________ From: erlang-questions-bounces@REDACTED on behalf of Garrett Smith Sent: Thursday, 1 September 2016 6:55 a.m. To: Michael Truog Cc: Erlang Questions Subject: Re: [erlang-questions] Why do "interface to language X" projects all seem to die out? On Wed, Aug 31, 2016 at 1:49 PM, Michael Truog wrote: > On 08/31/2016 08:50 AM, Garrett Smith wrote: >> > Based on https://github.com/hdima/erlport/issues/15 erlport isn't accepting > changes and is dead. There aren't many Erlang projects that don't have a bus count of ~ 1 :) Nonetheless this is a very impressive project and its patterns can be applied to any language. In terms of providing access to external libraries, I'd take this route over the distributed Erlang protocol. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From arshadansari27@REDACTED Thu Sep 1 08:27:08 2016 From: arshadansari27@REDACTED (Arshad Ansari) Date: Thu, 01 Sep 2016 06:27:08 +0000 Subject: [erlang-questions] How to manage C ports that are suppose to handle a very high number of requests In-Reply-To: References: Message-ID: Hello Daniel, > 1. You are initializing and destroying Lua context for every call. Can this be done just once for the whole program? I intend to keep lua context between calls but then I'm not sure how it will affect the subsequent calls. If the lua_State* is same for multiple calls then that state would have the file loaded once and I'm not sure if pushing and poping the arguments and return values from lua context would create problems or not. > 2. I count at least 5 read()/write() calls for each command which are somewhat expensive. Can that be reduced? Also consider batching a whole bunch of commands with a single read()/write(). read()/write() calls erlang to c-port? I simply followed a blog example do this, since I'm very new to both C as well as erlang. I'm not getting the link right now, I'll post it in this thread as soon as I find it. I will look into reducing those calls. Thanks for the reply and for pointing out areas of improvements. Regards, Arshad On Thu, Sep 1, 2016 at 12:58 AM Daniel Goertzen wrote: > I don't know much about Lua or why you had a stack overflow, but I have > some performance concerns about that C code: > > 1. You are initializing and destroying Lua context for every call. Can > this be done just once for the whole program? > > 2. I count at least 5 read()/write() calls for each command which are > somewhat expensive. Can that be reduced? Also consider batching a whole > bunch of commands with a single read()/write(). > > Regards, > Dan. > > On Thu, Aug 25, 2016 at 8:01 AM Arshad Ansari > wrote: > >> Hello there, >> >> I had earlier asked about how to access LuaJIT from erlang [ >> http://erlang.org/pipermail/erlang-questions/2016-August/089939.html >> ] >> and based on the responses, I decided to go with C port. It was working all >> great. Except, when I tried to call the same C-Port [luajit] code from >> erlang-diameter server. Since the requests were high, but not very high >> (approx 10K per second), the code fails with stack overflow on c side. >> >> Now I thought, I would create a seperate C port for each requests but >> that would mean there will be around 10K c-port processes. I'm now >> wondering how to handle this size of requests from the c port. Any help or >> direction is appreciated. Please let me know if my question is not clear. >> I'm attaching the code to access lua that works with single instance of >> c-port process. >> >> Regards >> Arshad >> >> /************ CODE Details *********************/ >> >> erl_com.c contains code to send/receive data from c side >> port.c runs the lua code and has main >> script.lua >> relay.erl starts the relay server and c port to talk to lua >> relay_cb.erl handles requests and communicates with lua >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Thu Sep 1 08:29:36 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 1 Sep 2016 08:29:36 +0200 Subject: [erlang-questions] Backed 'maint' branch on GitHub Message-ID: <20160901062936.GA56594@erix.ericsson.se> Hi all! I had to back the 'maint' branch on GitHub because we accidentally did a merge in the GitHub tool when the merge should be made in our internal origin repository and then be pushed out. So if you fetched 'maint' sometime between yesterday (Aug 31 at 10:32 CET) and now (Sep 1 at 8:25 CET) you will need to refetch it. Best Regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From bjorn@REDACTED Thu Sep 1 10:18:18 2016 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 1 Sep 2016 10:18:18 +0200 Subject: [erlang-questions] sys_pre_expand will be removed in OTP 20 Message-ID: We plan to remove sys_pre_expand in OTP 20: https://github.com/erlang/otp/pull/1156 sys_pre_expand is an undocumented and unsupported module, but since it has been in Erlang/OTP since the beginning, we thought it better to give a heads up just in case. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From olivier.boudeville@REDACTED Thu Sep 1 11:27:16 2016 From: olivier.boudeville@REDACTED (BOUDEVILLE Olivier) Date: Thu, 1 Sep 2016 09:27:16 +0000 Subject: [erlang-questions] Type verification at runtime Message-ID: Hello, Supposing that I have a "type-as-a-term" description as the one we can obtain from ASTs (ex: { type, 1, list, [{type,1,tuple,[{type,1,float,[]}, {type,1,boolean,[]}]} ] }, which corresponds to the "[{float(),boolean()}]" textual specification), is there a simple way to write a function telling, for such specified type and for any given term, whether this term is a value of that type? If it's clearer, something akin to: -spec check_term_against_type( type_description(), term() ) -> boolean(). Maybe some code already do that? Side question: is there already an "Erlang-official" convention to express types as terms, i.e the type_description() part ? I guess it would be probably inspired from the AST forms, yet removing line numbers and possibly (if feasible) the type/user_type distinction. Thanks in advance for any hint! Best, Olivier. Olivier Boudeville EDF R&D, D?partement SINETICS, Groupe ASICS, Bureau O2-E10 7, Boulevard Gaspard Monge, 91120 Palaiseau, France T?l. : +33 (0)1 78 19 43 63 T?l. mobile : +33 (0)6 16 83 37 22 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 essen@REDACTED Thu Sep 1 11:30:30 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Thu, 1 Sep 2016 11:30:30 +0200 Subject: [erlang-questions] Type verification at runtime In-Reply-To: References: Message-ID: <45c38ad5-3a92-8afa-c9ae-a99a82c5c2cd@ninenines.eu> A while ago I wrote https://github.com/extend/sheriff for doing just that. It hasn't been touched in a while so it probably doesn't work with all types / at all, but it should be a good start. On 09/01/2016 11:27 AM, BOUDEVILLE Olivier wrote: > Hello, > > > > Supposing that I have a ?type-as-a-term? description as the one we can > obtain from ASTs (ex: { type, 1, list, > [{type,1,tuple,[{type,1,float,[]}, {type,1,boolean,[]}]} ] }, which > corresponds to the "[{float(),boolean()}]" textual specification), is > there a simple way to write a function telling, for such specified type > and for any given term, whether this term is a value of that type? > > If it?s clearer, something akin to: -spec check_term_against_type( > type_description(), term() ) -> boolean(). > > > > Maybe some code already do that? > > > > Side question: is there already an ?Erlang-official? convention to > express types as terms, i.e the type_description() part ? I guess it > would be probably inspired from the AST forms, yet removing line numbers > and possibly (if feasible) the type/user_type distinction. > > > > Thanks in advance for any hint! > > > > Best, > > > > Olivier. > > > > Olivier Boudeville > EDF R&D, D?partement SINETICS, Groupe ASICS, Bureau O2-E10 > > 7, Boulevard Gaspard Monge, 91120 Palaiseau, France > > T?l. : +33 (0)1 78 19 43 63 > > T?l. mobile : +33 (0)6 16 83 37 22 > > > > > 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 > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From bjorn@REDACTED Thu Sep 1 11:48:23 2016 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 1 Sep 2016 11:48:23 +0200 Subject: [erlang-questions] math ceil floor In-Reply-To: References: Message-ID: On Thu, Jun 2, 2016 at 11:56 AM, Dan Gudmundsson wrote: > Hi > I made pull request https://github.com/erlang/otp/pull/1084 which implements > ceil and floor in the math module. > There is a new pull request for floor/ceil: https://github.com/erlang/otp/pull/1145 It implements floor/ceil as guard BIFs, as well as in the math module. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From olivier.boudeville@REDACTED Thu Sep 1 13:39:21 2016 From: olivier.boudeville@REDACTED (BOUDEVILLE Olivier) Date: Thu, 1 Sep 2016 11:39:21 +0000 Subject: [erlang-questions] Type verification at runtime In-Reply-To: <45c38ad5-3a92-8afa-c9ae-a99a82c5c2cd@ninenines.eu> References: <45c38ad5-3a92-8afa-c9ae-a99a82c5c2cd@ninenines.eu> Message-ID: <33317633336f42a291f23d0fef59c1ba@PCYINTPEXMU011.NEOPROD.EDF.FR> Thanks Lo?c! Indeed Sheriff and its dependencies (parse_trans, erl_syntax_lib) look much promising to provide such a feature. If/when time permits, I will try to get inspiration from all these elements in order to be able to check at runtime terms against such types. Best, Olivier. Olivier Boudeville EDF R&D, D?partement SINETICS, Groupe ASICS, Bureau O2-E10 7, Boulevard Gaspard Monge, 91120 Palaiseau, France T?l. : +33 (0)1 78 19 43 63 T?l. mobile : +33 (0)6 16 83 37 22 -----Message d'origine----- De?: essen@REDACTED [mailto:essen@REDACTED] Envoy??: jeudi 1 septembre 2016 11:31 ??: BOUDEVILLE Olivier; erlang-questions@REDACTED Objet?: Re: [erlang-questions] Type verification at runtime A while ago I wrote https://github.com/extend/sheriff for doing just that. It hasn't been touched in a while so it probably doesn't work with all types / at all, but it should be a good start. On 09/01/2016 11:27 AM, BOUDEVILLE Olivier wrote: > Hello, > > > > Supposing that I have a ?type-as-a-term? description as the one we can > obtain from ASTs (ex: { type, 1, list, > [{type,1,tuple,[{type,1,float,[]}, {type,1,boolean,[]}]} ] }, which > corresponds to the "[{float(),boolean()}]" textual specification), is > there a simple way to write a function telling, for such specified > type and for any given term, whether this term is a value of that type? > > If it?s clearer, something akin to: -spec check_term_against_type( > type_description(), term() ) -> boolean(). > > > > Maybe some code already do that? > > > > Side question: is there already an ?Erlang-official? convention to > express types as terms, i.e the type_description() part ? I guess it > would be probably inspired from the AST forms, yet removing line > numbers and possibly (if feasible) the type/user_type distinction. > > > > Thanks in advance for any hint! > > > > Best, > > > > Olivier. > > > > Olivier Boudeville > EDF R&D, D?partement SINETICS, Groupe ASICS, Bureau O2-E10 > > 7, Boulevard Gaspard Monge, 91120 Palaiseau, France > > T?l. : +33 (0)1 78 19 43 63 > > T?l. mobile : +33 (0)6 16 83 37 22 > > > > > 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 > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang 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. From roberto@REDACTED Thu Sep 1 13:52:05 2016 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 1 Sep 2016 13:52:05 +0200 Subject: [erlang-questions] Mnesia callbacks for write operations Message-ID: All, I'd like to sync mnesia across clusters using a custom TCP transport, and would like to know if it is possible to have a method being called back when a write operation takes place, so to signal it to the other cluster through the transport. I've seen some mnesia backup modules but their function is a little obscure to me. Has anyone some pointers on this? Thank you, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From snar@REDACTED Thu Sep 1 14:12:51 2016 From: snar@REDACTED (Alexandre Snarskii) Date: Thu, 1 Sep 2016 15:12:51 +0300 Subject: [erlang-questions] Mnesia callbacks for write operations In-Reply-To: References: Message-ID: <20160901121251.GA17251@staff.retn.net> On Thu, Sep 01, 2016 at 01:52:05PM +0200, Roberto Ostinelli wrote: > All, > I'd like to sync mnesia across clusters using a custom TCP transport, and would > like to know if it is possible to have a method being called back when a write > operation takes place, so to signal it to the other cluster through the > transport. mnesia:subscribe({table, Table, detailed}), http://erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id81558 > I've seen some mnesia backup modules but their function is a little obscure to > me. Has anyone some pointers on this? > > Thank you, > r. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From roberto@REDACTED Thu Sep 1 15:19:13 2016 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 1 Sep 2016 15:19:13 +0200 Subject: [erlang-questions] Mnesia callbacks for write operations In-Reply-To: <20160901121251.GA17251@staff.retn.net> References: <20160901121251.GA17251@staff.retn.net> Message-ID: Thank you Alexandre, I understand you are referring to Table Events? mnesia:subscribe({table, Table, detailed}), > > http://erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id81558 > Thank you Alexandre, I understand you are referring to Table Events? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Sep 1 20:36:45 2016 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 1 Sep 2016 20:36:45 +0200 Subject: [erlang-questions] Why do "interface to language X" projects all seem to die out? In-Reply-To: <20160831141806.uviuy6ix3ldolhip@corelatus.se> References: <20160831141806.uviuy6ix3ldolhip@corelatus.se> Message-ID: On 08/31/2016 04:18 PM, Matthias Lang wrote: > Hi, > > Pretty much all of the "not built in to OTP" ways to connect to other > languages seem to have died, i.e. > > - EPI (C++). Last commit 2009. > - py_interface (Python). Last commit 2014. Freshest of the lot. > - edtk (C). Last release 2007. > - dryverl (C). Last release 2008. > - erlua (Lua). Project page dead. Author's email is dead. > - erlualib (last commit 2010). Github-linked company page dead. > > Can anyone offer some experiences or ideas why? > > Could it be that these types of solutions are rarely needed? Maybe > NIFs are unbeatable for the "narrow interface, no state, high > performance" cases and port programs with hand-rolled interfaces most > of the rest. FYIW, we have developed Nifty [1], a NIF interface generator, i.e. a tool that automates the process of creating NIF libraries from C header files containing declarations of types and functions that the C library supplies. Among other features, Nifty provides support for dirty schedulers and support for safe execution via separate Erlang node. Its code is since 2014 on GitHub [2]. A talk and paper titled "The Nifty Way to Call Hell from Heaven" will be presented at the Erlang Workshop in late September 2016. Comments, suggestions for improvements, pull requests, etc. are welcome! Kostis [1] http://parapluu.github.io/nifty/ [2] https://github.com/parapluu/nifty [3] http://parapluu.github.io/nifty/erlang16-preprint.pdf From perkrovos@REDACTED Thu Sep 1 20:00:08 2016 From: perkrovos@REDACTED (nesvarbu Pavarde) Date: Thu, 1 Sep 2016 21:00:08 +0300 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? Message-ID: Why create illusion that you are sending a Fun to remote node to execute in a new process? If client node has to have same module loadable with the Fun defined as a server node anyway. Why not only spawn(Node, M, F, A) then, which makes it clear that you are sending a definition of a function call, not Fun itself. I am experimenting with distributed Erlang and want it to pass clojures around "willy nilly", even through network. "Code is data" kinda thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathaniel@REDACTED Thu Sep 1 22:16:44 2016 From: nathaniel@REDACTED (Nathaniel Waisbrot) Date: Thu, 1 Sep 2016 16:16:44 -0400 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: Message-ID: <9D61BA20-3951-4D01-A253-F27456AE1D6E@waisbrot.net> > Why create illusion that you are sending a Fun to remote node to execute in a new process? If client node has to have same module loadable with the Fun defined as a server node anyway. Why not only spawn(Node, M, F, A) then, which makes it clear that you are sending a definition of a function call, not Fun itself. > I am experimenting with distributed Erlang and want it to pass clojures around "willy nilly", even through network. "Code is data" kinda thing. http://stackoverflow.com/q/39255471/1220269 Are you the same person as "Sharas" who posted this question on StackOverflow, or are you just copy/pasting it to this list? It seems like several people already put good effort into answering there. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From matthias@REDACTED Fri Sep 2 09:09:05 2016 From: matthias@REDACTED (Matthias Lang) Date: Fri, 2 Sep 2016 09:09:05 +0200 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: Message-ID: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Hi, Thanks Nathaniel for pointing out that this is a dupe of a stackoverflow question. It's good form to indicate when you're aware of previous discussion and, perhaps, why you're not satisifed. My guess is OP isn't satisifed because a) The two top-voted stack overflow answers gloss over the difference between funs defined in the shell and funs defined in code. b) Neither of the top-voted answers deals with the question the OP opens with. Kresten's blog post, which is linked from the stack overflow comments, is good, but it causes confusion for people who don't read it carefully. One source of confusion is that it gives an example of a fun which _does_ include the definition, says that the definition isn't included and then, seven paragraphs later, explains that the first example did actually include the definition. Similarly, Joe has a blog post which was up on Hacker News (again?) just a few days ago with an example which borders on being overly cute: http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html this similarly creates the impression that all you have to do is send a fun to server and you're done, not even giving a nod to the problem that you need to get the code to all 1171 nodes he wants to run the code on. --- I'd like to wrap up with a proper answer, the sort that Richard Carlsson might write, but I don't have time for that. It would: - cover the difference between funs defined in the shell, funs which contain actual code and/or variables and funs which are pure references, e.g. fun io:fwrite/2 - comment on the OP's mis-use of the word "definition" and cleaning up other language sloppiness to avoid disagreements and confusion caused by misunderstanding. - talk about how it's nice that the concept of funs is the same across lots of different uses, i.e. passing to lists:filter/2, sending to a local process, sending to a remote process and spawning, and that the cost of getting a fairly harmless surprise or two in the distributed case is low compared to the benefit of the concept being so simple. - speculate on the possibility of an Erlang system which automaticaly distributes code when you send a fun. It seems possible, the fun includes information about where it came from. My guess is that there's a simple, sane, useful case of distributed Erlang, which the case where you make sure all nodes have the same code from the start. Then there's the case where nodes don't all have the same code, and that case is messy and complicated. There are problems such as "what do you do if the fun refers to a different version of a module which is already loaded on the receiving node?". This feels like research, not "getting things done", and I'm into the latter. Matthias ---------------------------------------------------------------------- Date: 01. September 2016 From: nesvarbu Pavarde To erlang-questions@REDACTED Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? > Why create illusion that you are sending a Fun to remote node to execute in > a new process? If client node has to have same module loadable with the Fun > defined as a server node anyway. Why not only spawn(Node, M, F, A) then, > which makes it clear that you are sending a definition of a function call, > not Fun itself. > I am experimenting with distributed Erlang and want it to pass clojures > around "willy nilly", even through network. "Code is data" kinda thing. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ritchie.ua@REDACTED Fri Sep 2 11:11:32 2016 From: ritchie.ua@REDACTED (Gonchar Denis) Date: Fri, 2 Sep 2016 11:11:32 +0200 Subject: [erlang-questions] xref doesn't show all the calls Message-ID: Hi, all. I noticed that *xref* doesn't detect some of the calls. here is the simple test module: -module(test). -compile(export_all). test()-> lists:reverse([]), lists:keyfind(a,1,[]). and* xref* query to get the calls from the module: *1>* c(test,[debug_info]). {ok,test} *2>* xref:start(s). {ok,<0.41.0>} *3>* xref:add_directory(s,"."). {ok,[test]} *4>* xref:q(s, "E | test:Mod"). {ok,[{{test,test,0},{lists,reverse,1}}]} *5>* xref:stop(s). stopped can anyone explain why *xref* doesn't detect* lists:keyfind/3* call? Regards, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Sep 2 16:45:12 2016 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 2 Sep 2016 16:45:12 +0200 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Message-ID: I posted some information about why things are as they are: http://erlang.org/pipermail/erlang-questions/2016-July/089809.html The reason is historical - In the first distributed erlang all nodes accessed a common file store - this is no longer true when the nodes have separated stores. "All you have to do" (TM) is make sure all nodes have the same code before sending funs around. This is not easy in the general case, since all the code the fun calls also needs to be copied, and all the code it calls and so on. If the code is in more than two versions or changing in different places in the system at the same time this sould be very tricky. A "stop all nodes, send code to all nodes, restart all nodes" solution is easy to implement and pretty foolproof. Not elegant but it gets the job done. /Joe On Fri, Sep 2, 2016 at 9:09 AM, Matthias Lang wrote: > Hi, > > Thanks Nathaniel for pointing out that this is a dupe of a > stackoverflow question. It's good form to indicate when you're > aware of previous discussion and, perhaps, why you're not satisifed. > > My guess is OP isn't satisifed because > > a) The two top-voted stack overflow answers gloss over the > difference between funs defined in the shell and funs > defined in code. > > b) Neither of the top-voted answers deals with the question the > OP opens with. > > Kresten's blog post, which is linked from the stack overflow comments, > is good, but it causes confusion for people who don't read it > carefully. One source of confusion is that it gives an example of a > fun which _does_ include the definition, says that the definition > isn't included and then, seven paragraphs later, explains that the > first example did actually include the definition. > > Similarly, Joe has a blog post which was up on Hacker News (again?) > just a few days ago with an example which borders on being overly cute: > > http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html > > this similarly creates the impression that all you have to do is send > a fun to server and you're done, not even giving a nod to the problem > that you need to get the code to all 1171 nodes he wants to run the > code on. > > --- > > > I'd like to wrap up with a proper answer, the sort that Richard > Carlsson might write, but I don't have time for that. It would: > > - cover the difference between funs defined in the shell, funs which > contain actual code and/or variables and funs which are pure > references, e.g. fun io:fwrite/2 > > - comment on the OP's mis-use of the word "definition" and cleaning > up other language sloppiness to avoid disagreements and confusion > caused by misunderstanding. > > - talk about how it's nice that the concept of funs is the same across > lots of different uses, i.e. passing to lists:filter/2, sending > to a local process, sending to a remote process and spawning, and > that the cost of getting a fairly harmless surprise or two in the > distributed case is low compared to the benefit of the concept being > so simple. > > - speculate on the possibility of an Erlang system which > automaticaly distributes code when you send a fun. It seems > possible, the fun includes information about where it came from. > > My guess is that there's a simple, sane, useful case of > distributed Erlang, which the case where you make sure all nodes > have the same code from the start. > > Then there's the case where nodes don't all have the same code, > and that case is messy and complicated. There are problems such as > "what do you do if the fun refers to a different version of a module > which is already loaded on the receiving node?". This feels like > research, not "getting things done", and I'm into the latter. > > Matthias > > ---------------------------------------------------------------------- > > Date: 01. September 2016 > From: nesvarbu Pavarde > To erlang-questions@REDACTED > Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? > > >> Why create illusion that you are sending a Fun to remote node to execute in >> a new process? If client node has to have same module loadable with the Fun >> defined as a server node anyway. Why not only spawn(Node, M, F, A) then, >> which makes it clear that you are sending a definition of a function call, >> not Fun itself. >> I am experimenting with distributed Erlang and want it to pass clojures >> around "willy nilly", even through network. "Code is data" kinda thing. > >> _______________________________________________ >> 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 netch@REDACTED Fri Sep 2 16:56:40 2016 From: netch@REDACTED (Valentin Nechayev) Date: Fri, 2 Sep 2016 17:56:40 +0300 Subject: [erlang-questions] math ceil floor In-Reply-To: References: Message-ID: <20160902145640.GA606@netch.kiev.ua> Fri, Jun 03, 2016 at 23:37:48, samuelrivas wrote about "Re: [erlang-questions] math ceil floor": > What is the use case when you want floor/ceil to return a float and > not an integer in Erlang? C provides floor() and ceil() according to IEEE754 that requires * sourceFormat roundToIntegralTowardPositive(source) * sourceFormat roundToIntegralTowardNegative(source) format isn't changed. So, operations with float result will be direct mapping of those of implementation, with all consequential features, as efficiency. A variant of conversion of the result to integer will be as efficient as explicit conversion after math library floor/ceil, except a cost to chain two Erlang calls. -netch- From matthias@REDACTED Fri Sep 2 23:05:28 2016 From: matthias@REDACTED (Matthias Lang) Date: Fri, 2 Sep 2016 23:05:28 +0200 Subject: [erlang-questions] xref doesn't show all the calls In-Reply-To: References: Message-ID: <20160902210527.uytx3aymo4mxgo7t@corelatus.se> On 02. September 2016, Gonchar Denis wrote: > I noticed that *xref* doesn't detect some of the calls. ... > lists:reverse([]), > lists:keyfind(a,1,[]). ... > *4>* xref:q(s, "E | test:Mod"). > {ok,[{{test,test,0},{lists,reverse,1}}]} ... > can anyone explain why *xref* doesn't detect* lists:keyfind/3* call? Clue: 2> erlang:is_builtin(lists, keyfind, 3). true 3> erlang:is_builtin(lists, reverse, 1). false use the 'builtins' option in xref. --- Erlang/OTP 18 [erts-7.3] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.3 (abort with ^G) 1> c(test,[debug_info]). {ok,test} 2> xref:start(s). {ok,<0.41.0>} 3> xref:add_directory(s,".", [builtins]). {error,xref_base,{invalid_options,[builtins]}} 4> xref:add_directory(s,".", [{builtins, true}]). Skipping ./a.beam (no debug information) {ok,[test]} 5> xref:q(s, "E | test:Mod"). {ok,[{{test,test,0},{lists,keyfind,3}}, {{test,test,0},{lists,reverse,1}}]} Matt From be.dmitry@REDACTED Sun Sep 4 10:35:44 2016 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Sun, 04 Sep 2016 18:35:44 +1000 Subject: [erlang-questions] math ceil floor In-Reply-To: <20160902145640.GA606@netch.kiev.ua> References: <20160902145640.GA606@netch.kiev.ua> Message-ID: <0C074E11-A4C9-4D2A-B5A6-6BE902282DF4@gmail.com> Another possibility would be to return the argument if it is already an integer. It would be convenient for long integers as no loss of precision would come from conversion to a float. On 3 September 2016 00:56:40 GMT+10:00, Valentin Nechayev wrote: >Fri, Jun 03, 2016 at 23:37:48, samuelrivas wrote about "Re: >[erlang-questions] math ceil floor": > >> What is the use case when you want floor/ceil to return a float and >> not an integer in Erlang? > >C provides floor() and ceil() according to IEEE754 that requires > >* sourceFormat roundToIntegralTowardPositive(source) >* sourceFormat roundToIntegralTowardNegative(source) > >format isn't changed. So, operations with float result will be direct >mapping of those of implementation, with all consequential features, >as efficiency. > >A variant of conversion of the result to integer will be as efficient >as explicit conversion after math library floor/ceil, except a cost to >chain >two Erlang calls. > > >-netch- >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Mon Sep 5 01:44:35 2016 From: matthias@REDACTED (Matthias Lang) Date: Mon, 5 Sep 2016 01:44:35 +0200 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Message-ID: <20160904234435.gv4ymic2ls2rocgu@corelatus.se> Hi, On 02. September 2016, Joe Armstrong wrote: > I posted some information about why things are as they are: > http://erlang.org/pipermail/erlang-questions/2016-July/089809.html Interesting thread, shame I missed it during summer. I thought a bit about how this could be hacked together and came up with two ideas. One is to hack the code server. Tony showed how to do that later in the thread you linked above. The other is to use the 'inet' loader to do demand loading. I half expected that to require some hacking, but it actually works straight off. Here's an example of receiving a fun from a remote node and running it without having a local copy of the .beam: >erl -sname a -loader inet -hosts 192.168.1.4 Erlang/OTP 18 [erts-7.3] [source] ... Eshell V7.3 (abort with ^G) (a@REDACTED)1> global:register_name(mml, self()). yes (a@REDACTED)2> Y = receive X -> X end. #Fun (a@REDACTED)3> code:is_loaded(cc). false (a@REDACTED)4> erlang:fun_info(Y, module). {module,cc} (a@REDACTED)5> erlang:fun_info(Y, pid). {pid,<7389.70.0>} (a@REDACTED)6> Y(). "this is a fun" The fun I sent was defined, in a .beam, like this: d() -> fun() -> "this is a fun" end. and I sent it from the remote node like this: global:whereis_name(mml) ! cc:d(). the remote node was running a boot server, i.e. erl_boot_server:start(["192.168.1.4"]). --- One limitation is that the code server has to contain all the code that might be run in the network of nodes. You can specify multiple code servers (the -hosts argument), but they don't get used concurrently, it's just fail-over. So you can't have some modules on one node and some on another and have it magically work. Another limitation is that you can't run a code server on a diskless node. 'erl_boot_server' uses erl_prim_loader:prim_get_file/2 which only reads from the filesystem, unlike erl_prim_loader:get_file/2. I'm not sure why, maybe just "keep it simple" and avoid problems with cyclic code server graphs. I briefly wondered why there's no 'get_code/1' BIF which gives you loaded code even if no .beam file is present. I then remembered that the beam loader rewrites things, so you'd have to store a copy of the .beam anyway to provide that. A comment at the top of 'erl_boot_server.erl' mentions CP and DP, so I'm guessing the feature is courtesty of AXD-301 (CP = Central Processor, DP = Device Processor) and also I'd guess that DPs were diskless. > The reason is historical - In the first distributed erlang all nodes > accessed a common file store - this is no longer true when the nodes > have separated stores. It looks like AXD-301 moved forwards on this, though in a pragmatic "change as little as possible" way. (I'm not advocating sending code around a distributed erlang system, I can't think of a practical use where "just start off with all code on all nodes" isn't the sane, robust approach. I just got curious.) Matt From ok@REDACTED Mon Sep 5 02:20:44 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 5 Sep 2016 12:20:44 +1200 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Message-ID: On 3/09/16 2:45 AM, Joe Armstrong wrote: > > "All you have to do" (TM) is make sure all nodes have the same > code before sending funs around. This is not easy in the general case, > since all the code the fun calls also needs to be copied, and all the > code it calls and so on. This could of course be done lazily, but that would (probably) lead to unexpected and quite long delays later on, which is a Bad Thing in a "soft real time" language. This may be the best reason for not even trying to do it (lazily OR eagerly). When you send a message to another node, you'd like to have some idea of how much you're sending and (in very rough terms) how long it's likely to take, but quite a small fun might drag in quite a lot of dependencies, or not, depending on how much code the sender and receiver already share. Something of the sort *can* be done. Kali Scheme used to let you send code around. Someone seems to be trying to revive it: http://community.schemewiki.org/kali-scheme/ http://community.schemewiki.org/?kali-scheme-revival In order to make something like this work, I think we really need something like Chris Brown's ideas for SafeErlang, a scheme in which multiple versions of modules can co-exist without confusion. > A "stop all nodes, send code to all nodes, restart all nodes" solution is > easy to implement and pretty foolproof. > > Not elegant but it gets the job done. I'm not sure that it's all that inelegant. You pay the price when you *expect* to pay the price, and you can check that the "upgrade" will land you in a sensible state before you make any change.. There is of course another possibility. If you need to send "pieces of behaviour" to another node, you can define a mini-language represented as Erlang data structures as part of the protocol, and send something over that is a *scrutable* data structure in which general Bad Things simply aren't expressible, and that can be interpreted or compiled to Erlang by the receiver as it chooses. "Stuff we can run" doesn't have to be Erlang any more than it has to be ARM assembly code. From Huiqing.Li@REDACTED Mon Sep 5 10:44:18 2016 From: Huiqing.Li@REDACTED (Li, Huiqing) Date: Mon, 5 Sep 2016 08:44:18 +0000 Subject: [erlang-questions] PEPM 2017 - Final Call for Papers Message-ID: <51AD8844B93AD3408D36923062C3847752E80D34@UK31S005EXS05.EEAD.EEINT.CO.UK> Dear All, Apologies if you receive multiple copies of this message. FINAL CALL FOR PAPERS Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM 2017) NEWS: Deadline extension to 30th September (see below) NEWS: Keynote talk by Neil Jones, DIKU (see below). http://conf.researchr.org/home/PEPM-2017 Paris, France, January 16th - 17th, 2017 (co-located with POPL 2017) PEPM is the premier forum for discussion of semantics-based program manipulation. The first ACM SIGPLAN PEPM symposium took place in 1991, and meetings have been held in affiliation with POPL every year since 2006. PEPM 2017 will be based on a broad interpretation of semantics-based program manipulation, reflecting the expanded scope of PEPM in recent years beyond the traditionally covered areas of partial evaluation and specialization. Specifically, PEPM 2017 will include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to maintain the dynamic and interactive nature of PEPM and to encourage participation by practitioners, we also solicit submissions of short papers, including tool demonstrations, and of posters. Scope ----- Topics of interest for PEPM 2017 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing applications of semantics-based program manipulation techniques in new domains. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme chairs. Submission categories and guidelines ------------------------------------ Three kinds of submissions will be accepted: Regular Research Papers, Short Papers and Posters. * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance and clarity. Regular research papers must not exceed 12 pages in ACM Proceedings style (including appendix). * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages in ACM Proceedings style (including appendix). * Posters should describe work relevant to the PEPM community, and must not exceed 2 pages in ACM Proceedings style. We invite poster submissions that present early work not yet ready for submission to a conference or journal, identify new research problems, showcase tools and technologies developed by the author(s), or describe student research projects. At least one author of each accepted contribution must attend the workshop and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Suggested topics, evaluation criteria, and writing guidelines for both research tool demonstration papers will be made available on the PEPM 2017 web site. Student participants with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses and other support. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page. Publication and special issue ----------------------------- All accepted papers, short papers and posters included, will appear in formal proceedings published by ACM Press. Accepted papers will be included in the ACM Digital Library. Authors of selected papers from PEPM 2016 and PEPM 2017 will also be invited to expand their papers for publication in a special issue of the journal Computer Languages, Systems and Structures (COMLAN, Elsevier). Keynote ------- Neil Jones (DIKU) will give the PEPM keynote talk, titled Compiling Untyped Lambda Calculus to Lower-level Code by Game Semantics and Partial Evaluation Best paper award ---------------- PEPM 2017 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Submission ---------- Papers should be submitted electronically via HotCRP. https://pepm17.hotcrp.com/ Authors using LaTeX to prepare their submissions should use the new improved SIGPLAN proceedings style, and specifically the sigplanconf.cls 9pt template. Important Dates --------------- UPDATE: following feedback from potential authors, we have extended the PEPM submission dates by two weeks to avoid clashes with other events. The new deadlines are consequently strict, and there will be no further extensions. For Regular Research Papers and Short Papers: * Abstract submission : Tuesday 27th September 2016 * Paper submission : Friday 30th September 2016 * Author notification : Friday 4th November 2016 * Camera ready : Monday 28th November 2016 For Posters: * Poster submission : Tuesday 8th November 2016 * Author notification : Friday 18th November 2016 * Camera ready : Monday 28th November 2016 PEPM workshop: * Workshop : Monday 16th - Tuesday 17th January 2017 The proceedings will be published 2 weeks pre-conference. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. (For those rare conferences whose proceedings are published in the ACM Digital Library after the conference is over, the official publication date remains the first day of the conference.). PEPM'17 Programme Committee --------------------------- Elvira Albert (Complutense University of Madrid, Spain) Don Batory (University of Texas at Austin, USA) Martin Berger (University of Sussex, UK) Sebastian Erdweg (TU Delft, Netherlands) Andrew Farmer (Facebook, USA) Matthew Flatt (University of Utah, USA) John Gallagher (Roskilde University, Denmark) Robert Gl??ck (DIKU, Denmark) Jurriaan Hage (Utrecht University, Netherlands) Zhenjiang Hu (National Institute of Informatics, Japan) Yukiyoshi Kameyama (University of Tsukuba, Japan) Ilya Klyuchnikov (Facebook, UK) Huiqing Li (EE, UK) Annie Liu (Stony Brook University, USA) Markus P??schel (ETH Zurich, Switzerland) Ryosuke SATO (University of Tokyo, Japan) Sven-Bodo Scholz (Heriot-Watt University, UK) Ulrik Schultz (co-chair) (University of Southern Denmark) Ilya Sergey (University College London, UK) Chung-chieh Shan (Indiana University, USA) Tijs van der Storm (Centrum Wiskunde & Informatica, Netherlands) Jeremy Yallop (co-chair) (University of Cambridge, UK) NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. EE Limited Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW Registered in England no: 02382161 EE Limited is a wholly owned subsidiary of: British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc@REDACTED Mon Sep 5 13:25:41 2016 From: marc@REDACTED (Marc Worrell) Date: Mon, 5 Sep 2016 13:25:41 +0200 Subject: [erlang-questions] [ANN] Zotonic 0.20 released Message-ID: <93AE078F-21BE-4535-9CCD-ED2741F41902@worrell.nl> Hi, Zotonic is the Erlang Content Management System and Framework. We just released version 0.20, which is a maintenance release. The release notes are at: https://github.com/zotonic/zotonic/releases/tag/0.20.0 There you can also download Zotonic. - The Zotonic Team From alex.arnon@REDACTED Tue Sep 6 07:23:50 2016 From: alex.arnon@REDACTED (Alex Arnon) Date: Tue, 6 Sep 2016 08:23:50 +0300 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Message-ID: Would an Erlang AST do it? On Mon, Sep 5, 2016 at 3:20 AM, Richard A. O'Keefe wrote: > [SNIP] > > > There is of course another possibility. > If you need to send "pieces of behaviour" to another node, > you can define a mini-language represented as Erlang > data structures as part of the protocol, and send something > over that is a *scrutable* data structure in which general > Bad Things simply aren't expressible, and that can be > interpreted or compiled to Erlang by the receiver as it > chooses. "Stuff we can run" doesn't have to be Erlang > any more than it has to be ARM assembly code. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehsan.tck@REDACTED Tue Sep 6 14:24:05 2016 From: ehsan.tck@REDACTED (Ehsan Mohammadi) Date: Tue, 06 Sep 2016 12:24:05 +0000 Subject: [erlang-questions] Diameter Relay detach Message-ID: hi diameter document in handle_request section says: *{relay, Opts}* *...* The returned Opts should not specify detach this means when we relay requests we should wait for it`s answer before relaying next request. i have a server which it`s response time is 0.5 so i can send up to 20 packet per sec, but if i can send request asynchronously it handles hundreds of packets per second. if i send more than 20 packet per second to my relay agent requests get timeout error and relay sends back a CCA with DIAMETER_UNABLE_TO_DELIVER error had anyone same problem with this app? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Sep 7 02:08:00 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 7 Sep 2016 12:08:00 +1200 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Message-ID: <2f93f134-f79c-e7ea-0b83-2d31c5225845@cs.otago.ac.nz> On 6/09/16 5:23 PM, Alex Arnon wrote: > Would an Erlang AST do it? You missed the point. We *have* an Erlang AST. That can, of necessity, express ANYTHING that Erlang can. The great benefit of a mini-language is that it CAN'T. In general, such a mini-language > is a *scrutible* data structure in which general > Bad Things simply aren't expressible Accepting code from a remote source is always a risk, UNLESS it is tightly constrained so that you KNOW even before you look that it can't be so very bad. For example, if you want to write some sort of distributed game, and have players send "scripts" for their pieces to a game server, you want to KNOW that the scripts execute in bounded time and can only do game-related stuff. From josh.rubyist@REDACTED Wed Sep 7 10:37:39 2016 From: josh.rubyist@REDACTED (Josh Adams) Date: Wed, 7 Sep 2016 03:37:39 -0500 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Message-ID: > > "All you have to do" (TM) is make sure all nodes have the same > code before sending funs around. This is not easy in the general case, > since all the code the fun calls also needs to be copied, and all the > code it calls and so on. If the code is in more than two versions or > changing in different places in the system at the same time this sould > be very tricky. I have been waiting for a chance to interject something into exactly this sort of discussion by Really Smart People. Unison is a language. Here's its 'about' page: http://unisonweb.org/2015-05-07/about.html#post-start . Search for "distributed systems" to get to the meatiest/most-fun bit of the intro. Here's a brief and incomplete/wrong summary: - It's a typed language. - It has distribution primitives. - It has a semantic editor - programs don't require lexing/parsing from unicode. - It covers the fundamental things Joe mentions in this article on IPFS: http://joearms.github.io/2015/03/12/The_web_of_names.html - Here's a nice deeper-dive into its API for distributed evaluation / distributed systems: http://unisonweb.org/2015-06-02/distributed-evaluation.html I desperately want to hear the super smart people on this Mailing List tell me (why it's dumb | zomg that's so neat! | we tried this in 2003 with BitDonkey2000 and it didn't work fundamentally because X | more nuanced responses). Has anyone seen this before and/or on seeing it now does any of it strike you as interesting? (also, and related: geez I wish I 'got' session types) -Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.arnon@REDACTED Wed Sep 7 12:15:27 2016 From: alex.arnon@REDACTED (Alex Arnon) Date: Wed, 7 Sep 2016 13:15:27 +0300 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: <2f93f134-f79c-e7ea-0b83-2d31c5225845@cs.otago.ac.nz> References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> <2f93f134-f79c-e7ea-0b83-2d31c5225845@cs.otago.ac.nz> Message-ID: I know we have an AST, my question should have been phrased "would the Erlang AST itself be appropriate?". Would it be appropriate in the scenario, where peer servers ship fun invocations around, without the need for security checks and constraints? On Wed, Sep 7, 2016 at 3:08 AM, Richard A. O'Keefe wrote: > > > On 6/09/16 5:23 PM, Alex Arnon wrote: > >> Would an Erlang AST do it? >> > > You missed the point. > We *have* an Erlang AST. > That can, of necessity, express ANYTHING that Erlang can. > The great benefit of a mini-language is that it CAN'T. > In general, such a mini-language > > is a *scrutible* data structure in which general >> Bad Things simply aren't expressible >> > > Accepting code from a remote source is always a risk, > UNLESS it is tightly constrained so that you KNOW even > before you look that it can't be so very bad. > For example, if you want to write some sort of > distributed game, and have players send "scripts" for > their pieces to a game server, you want to KNOW that > the scripts execute in bounded time and can only do > game-related stuff. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perkrovos@REDACTED Wed Sep 7 16:49:47 2016 From: perkrovos@REDACTED (Sharas) Date: Wed, 07 Sep 2016 10:49:47 -0400 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: <2f93f134-f79c-e7ea-0b83-2d31c5225845@cs.otago.ac.nz> References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> <2f93f134-f79c-e7ea-0b83-2d31c5225845@cs.otago.ac.nz> Message-ID: <21500DC4-6FDF-4AE9-BCE8-CF6D2900D9D8@gmail.com> It sounds to me as a question of authorization. Clients could potentially send arbitrary code to execute, and recipient node should be able to decide which clients are authorized for running the code on it. On September 6, 2016 8:08:00 PM EDT, "Richard A. O'Keefe" wrote: > > >On 6/09/16 5:23 PM, Alex Arnon wrote: >> Would an Erlang AST do it? > >You missed the point. >We *have* an Erlang AST. >That can, of necessity, express ANYTHING that Erlang can. >The great benefit of a mini-language is that it CAN'T. >In general, such a mini-language > >> is a *scrutible* data structure in which general >> Bad Things simply aren't expressible > >Accepting code from a remote source is always a risk, >UNLESS it is tightly constrained so that you KNOW even >before you look that it can't be so very bad. >For example, if you want to write some sort of >distributed game, and have players send "scripts" for >their pieces to a game server, you want to KNOW that >the scripts execute in bounded time and can only do >game-related stuff. > >_______________________________________________ >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 Wed Sep 7 17:12:00 2016 From: donpedrothird@REDACTED (John Doe) Date: Wed, 7 Sep 2016 18:12:00 +0300 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> <2f93f134-f79c-e7ea-0b83-2d31c5225845@cs.otago.ac.nz> Message-ID: Also don't forget that funs are actually closures, so it is necessary to pass the context as well. 2016-09-07 13:15 GMT+03:00 Alex Arnon : > I know we have an AST, my question should have been phrased "would the > Erlang AST itself be appropriate?". > Would it be appropriate in the scenario, where peer servers ship fun > invocations around, without the need for security checks and constraints? > > On Wed, Sep 7, 2016 at 3:08 AM, Richard A. O'Keefe > wrote: > >> >> >> On 6/09/16 5:23 PM, Alex Arnon wrote: >> >>> Would an Erlang AST do it? >>> >> >> You missed the point. >> We *have* an Erlang AST. >> That can, of necessity, express ANYTHING that Erlang can. >> The great benefit of a mini-language is that it CAN'T. >> In general, such a mini-language >> >> is a *scrutible* data structure in which general >>> Bad Things simply aren't expressible >>> >> >> Accepting code from a remote source is always a risk, >> UNLESS it is tightly constrained so that you KNOW even >> before you look that it can't be so very bad. >> For example, if you want to write some sort of >> distributed game, and have players send "scripts" for >> their pieces to a game server, you want to KNOW that >> the scripts execute in bounded time and can only do >> game-related stuff. >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felixgallo@REDACTED Wed Sep 7 17:30:49 2016 From: felixgallo@REDACTED (Felix Gallo) Date: Wed, 7 Sep 2016 08:30:49 -0700 Subject: [erlang-questions] SD-Erlang Message-ID: One of the interesting things to emerge from the RELEASE project ( http://www.release-project.eu/) was SD-Erlang ( http://www.sciencedirect.com/science/article/pii/S0743731516000034), which explored creating a non-fully-meshed distribution network, in order to enable certain scalability optimizations with high node counts. It looks like this was built off a fork of 17.4 ( https://github.com/release-project/otp/tree/17.4-rebased), which even now fades regretfully into the distance of our memories like the morning dew. Are there any thoughts or plans in OTP proper to either (a) integrate SD-Erlang, or (b) to take the learnings, as was done with the whatsapp timer wheel patch, and create a new system? F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From t@REDACTED Wed Sep 7 17:57:36 2016 From: t@REDACTED (Tristan Sloughter) Date: Wed, 07 Sep 2016 08:57:36 -0700 Subject: [erlang-questions] Erlang/OTP libraries/modules replaced by third party projects Message-ID: <1473263856.3030071.718552769.44285A4B@webmail.messagingengine.com> I'm looking to collect information on why certain functionality found in Erlang/OTP is usually handled instead by a third party library in people's projects. This could be bugs, missing functionality, poor interface, performance, etc. Please comment on this gist or reply to this email: https://gist.github.com/tsloughter/4d18c474f009dd3a3eeb094f8933e90b I don't know exactly what I'll do after having this information collected. But I hope to somehow use it to both be able to create/suggest improvements to built-in libraries and create documentation to help users decide if and when they should add a dependency to their project. -- Tristan Sloughter t@REDACTED From perkrovos@REDACTED Thu Sep 8 00:12:37 2016 From: perkrovos@REDACTED (Sharas) Date: Wed, 07 Sep 2016 18:12:37 -0400 Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node? In-Reply-To: References: <20160902070905.eznqxuhld2tlfaxi@corelatus.se> Message-ID: "A "stop all nodes, send code to all nodes, restart all nodes" solution is easy to implement and pretty foolproof." Where did 9 9ines availability with erlang go then? If you have to stop nodes. How do you do code changes without stopping all nodes? The bit that inspired my about erlang is ability to deploy your code in small batches and evolve your system as you learn. Mashes well with "let it crash" in my understanding: Let it crash, as in don't try to predict what will go wrong, learn from things going wrong, and adapt (change code) fast. On September 2, 2016 10:45:12 AM EDT, Joe Armstrong wrote: >I posted some information about why things are as they are: > >http://erlang.org/pipermail/erlang-questions/2016-July/089809.html > >The reason is historical - In the first distributed erlang all nodes >accessed a common file store - this is no longer true when the nodes >have separated stores. > >"All you have to do" (TM) is make sure all nodes have the same >code before sending funs around. This is not easy in the general case, >since all the code the fun calls also needs to be copied, and all the >code it calls and so on. If the code is in more than two versions or >changing in different places in the system at the same time this sould >be very tricky. > >A "stop all nodes, send code to all nodes, restart all nodes" solution >is >easy to implement and pretty foolproof. > >Not elegant but it gets the job done. > >/Joe > >On Fri, Sep 2, 2016 at 9:09 AM, Matthias Lang >wrote: >> Hi, >> >> Thanks Nathaniel for pointing out that this is a dupe of a >> stackoverflow question. It's good form to indicate when you're >> aware of previous discussion and, perhaps, why you're not satisifed. >> >> My guess is OP isn't satisifed because >> >> a) The two top-voted stack overflow answers gloss over the >> difference between funs defined in the shell and funs >> defined in code. >> >> b) Neither of the top-voted answers deals with the question the >> OP opens with. >> >> Kresten's blog post, which is linked from the stack overflow >comments, >> is good, but it causes confusion for people who don't read it >> carefully. One source of confusion is that it gives an example of a >> fun which _does_ include the definition, says that the definition >> isn't included and then, seven paragraphs later, explains that the >> first example did actually include the definition. >> >> Similarly, Joe has a blog post which was up on Hacker News (again?) >> just a few days ago with an example which borders on being overly >cute: >> >> http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html >> >> this similarly creates the impression that all you have to do is send >> a fun to server and you're done, not even giving a nod to the problem >> that you need to get the code to all 1171 nodes he wants to run the >> code on. >> >> --- >> >> >> I'd like to wrap up with a proper answer, the sort that Richard >> Carlsson might write, but I don't have time for that. It would: >> >> - cover the difference between funs defined in the shell, funs >which >> contain actual code and/or variables and funs which are pure >> references, e.g. fun io:fwrite/2 >> >> - comment on the OP's mis-use of the word "definition" and cleaning >> up other language sloppiness to avoid disagreements and confusion >> caused by misunderstanding. >> >> - talk about how it's nice that the concept of funs is the same >across >> lots of different uses, i.e. passing to lists:filter/2, sending >> to a local process, sending to a remote process and spawning, and >> that the cost of getting a fairly harmless surprise or two in the >> distributed case is low compared to the benefit of the concept >being >> so simple. >> >> - speculate on the possibility of an Erlang system which >> automaticaly distributes code when you send a fun. It seems >> possible, the fun includes information about where it came from. >> >> My guess is that there's a simple, sane, useful case of >> distributed Erlang, which the case where you make sure all nodes >> have the same code from the start. >> >> Then there's the case where nodes don't all have the same code, >> and that case is messy and complicated. There are problems such >as >> "what do you do if the fun refers to a different version of a >module >> which is already loaded on the receiving node?". This feels like >> research, not "getting things done", and I'm into the latter. >> >> Matthias >> >> >---------------------------------------------------------------------- >> >> Date: 01. September 2016 >> From: nesvarbu Pavarde >> To erlang-questions@REDACTED >> Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if >Node has to have the same module loadable as a client node? >> >> >>> Why create illusion that you are sending a Fun to remote node to >execute in >>> a new process? If client node has to have same module loadable with >the Fun >>> defined as a server node anyway. Why not only spawn(Node, M, F, A) >then, >>> which makes it clear that you are sending a definition of a function >call, >>> not Fun itself. >>> I am experimenting with distributed Erlang and want it to pass >clojures >>> around "willy nilly", even through network. "Code is data" kinda >thing. >> >>> _______________________________________________ >>> 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 Sep 7 20:05:35 2016 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Wed, 7 Sep 2016 20:05:35 +0200 Subject: [erlang-questions] SD-Erlang In-Reply-To: References: Message-ID: 2016-09-07 17:30 GMT+02:00 Felix Gallo : > > Are there any thoughts or plans in OTP proper to either (a) integrate > SD-Erlang, or (b) to take the learnings, as was done with the whatsapp > timer wheel patch, and create a new system? > > I'll answer b) First, keep in mind that WhatsApp patches are highly specific to their application and not optimal everywhere else. I'm not quite sure which timer wheel patch you are referring to but I suspect it's the "multiple wheels" patch. OTP implemented multiple timer wheels in 18.0 along with numerous other optimizations. // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn-egil.xb.dahlberg@REDACTED Wed Sep 7 20:12:22 2016 From: bjorn-egil.xb.dahlberg@REDACTED (=?iso-8859-1?Q?Bj=F6rn-Egil_Dahlberg_XB?=) Date: Wed, 7 Sep 2016 18:12:22 +0000 Subject: [erlang-questions] SD-Erlang In-Reply-To: References: , Message-ID: Never mind. I misread the question. // egil Sent from my iPhone 7 sep. 2016 kl. 20:05 skrev Bj?rn-Egil Dahlberg >: 2016-09-07 17:30 GMT+02:00 Felix Gallo >: Are there any thoughts or plans in OTP proper to either (a) integrate SD-Erlang, or (b) to take the learnings, as was done with the whatsapp timer wheel patch, and create a new system? I'll answer b) First, keep in mind that WhatsApp patches are highly specific to their application and not optimal everywhere else. I'm not quite sure which timer wheel patch you are referring to but I suspect it's the "multiple wheels" patch. OTP implemented multiple timer wheels in 18.0 along with numerous other optimizations. // 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 natalia.chechina@REDACTED Wed Sep 7 19:26:23 2016 From: natalia.chechina@REDACTED (Natalia Chechina) Date: Wed, 7 Sep 2016 18:26:23 +0100 Subject: [erlang-questions] SD-Erlang In-Reply-To: References: Message-ID: Hello Felix, Nice to hear that you find the work interesting. Yes, currently the latest SD Erlang version is based on 17.4. The good news is that we've got some money for a 9 months work (starting from October 2016, actually) to clean up SD Erlang related modules (e.g. do comprehensive testing, separate currently existing in OTP and SD Erlang specific functionality, conform with Erlang OTP requirements). In other words, move from academic to industrial standards. So, SD Erlang will be moved to the latest version very soon :). Input, advice on how to better approach the task, and friendly criticism is very welcome :). Best wishes, Natalia. On 7 September 2016 at 16:30, Felix Gallo wrote: > One of the interesting things to emerge from the RELEASE project ( > http://www.release-project.eu/) was SD-Erlang ( > http://www.sciencedirect.com/science/article/pii/S0743731516000034), > which explored creating a non-fully-meshed distribution network, in order > to enable certain scalability optimizations with high node counts. > > It looks like this was built off a fork of 17.4 ( > https://github.com/release-project/otp/tree/17.4-rebased), which even now > fades regretfully into the distance of our memories like the morning dew. > > Are there any thoughts or plans in OTP proper to either (a) integrate > SD-Erlang, or (b) to take the learnings, as was done with the whatsapp > timer wheel patch, and create a new system? > > F. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Natalia Chechina -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.m.andersson@REDACTED Wed Sep 7 20:41:27 2016 From: rickard.m.andersson@REDACTED (Rickard Andersson) Date: Wed, 7 Sep 2016 21:41:27 +0300 Subject: [erlang-questions] SD-Erlang In-Reply-To: References: Message-ID: <1298a2f9-4c5f-56e8-ca8b-91bde55dccca@gmail.com> There is this talk: https://www.youtube.com/watch?v=usEs3GPnZDg On 07-Sep-16 18:30, Felix Gallo wrote: > One of the interesting things to emerge from the RELEASE project > (http://www.release-project.eu/) was SD-Erlang > (http://www.sciencedirect.com/science/article/pii/S0743731516000034), > which explored creating a non-fully-meshed distribution network, in > order to enable certain scalability optimizations with high node counts. > > It looks like this was built off a fork of 17.4 > (https://github.com/release-project/otp/tree/17.4-rebased), which even > now fades regretfully into the distance of our memories like the > morning dew. > > Are there any thoughts or plans in OTP proper to either (a) integrate > SD-Erlang, or (b) to take the learnings, as was done with the whatsapp > timer wheel patch, and create a new system? > > F. > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted.ml.erlang@REDACTED Thu Sep 8 03:39:13 2016 From: ted.ml.erlang@REDACTED (Ted Burghart) Date: Wed, 7 Sep 2016 21:39:13 -0400 Subject: [erlang-questions] [ann] Rebar3 raw resource provider Message-ID: Possibly ready for primetime, the ?raw? resource provider brings back an easy to use replacement for the [raw] option that?s no longer supported in rebar3. The current version squashes all know bugs, and you?re invited to take it for a spin from https://github.com/tburghart/rebar_raw_resource As always, comments and suggestions are welcome. ? Ted From aeyakovenko@REDACTED Thu Sep 8 18:58:49 2016 From: aeyakovenko@REDACTED (Anatoly Yakovenko) Date: Thu, 08 Sep 2016 16:58:49 +0000 Subject: [erlang-questions] relup with rebar3 Message-ID: anyone familiar with this error: $ ./rebar3 relup ===> Verifying dependencies... ===> Compiling minuteman ===> Starting relx build process ... ===> Resolving OTP Applications from directories: /home/ayakovenko/Public/minuteman/_build/default/lib /home/ayakovenko/erlangs/lib ===> Resolved minuteman-0.0.2 ===> Dev mode enabled, release will be symlinked ===> Including Erts from /home/ayakovenko/erlangs ===> release successfully created! ===> Starting relx build process ... ===> Resolving OTP Applications from directories: /home/ayakovenko/Public/minuteman/_build/default/lib /home/ayakovenko/erlangs/lib /home/ayakovenko/Public/minuteman/_build/default/rel ===> Resolving available OTP Releases from directories: /home/ayakovenko/Public/minuteman/_build/default/lib /home/ayakovenko/Public/minuteman/_build/default/rel ===> could not find app kernel {2,14,4} Thanks, Anatoly -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbartley@REDACTED Fri Sep 9 23:56:01 2016 From: nbartley@REDACTED (nato) Date: Fri, 9 Sep 2016 14:56:01 -0700 Subject: [erlang-questions] Trace erlang BIFs with dbg Message-ID: Are BIFs such as `length/1` part of the erlang module, or do BIFs live somewhere else then get masqueraded ... I am trying to trace functions like these with dbg, and nothing is yielded. For example, I am trying the following with no success... 1> dbg:tracer(), dbg:p(all, c). 2> dbg:tpl(erlang, length, x). 3> erlang:length( [] ). %% or simply `length([]).` Or, are my above dbg flags leaving the erlang module out... or... confused. From devangana@REDACTED Sat Sep 10 06:48:20 2016 From: devangana@REDACTED (Devangana Tarafdar) Date: Fri, 9 Sep 2016 23:48:20 -0500 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error Message-ID: Hello, I am trying to connect to a third party SNMP agent, using snmp manager (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running into a problem where the agent is returning this error on the manager calling sync_get: *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** handle_snmp_report -> entry with Domain: snmpUDPDomain Addr: {{xx,xxx,xxx,xxx},161} ReqId: 37078226 Rep: {invalid_sec_info,[{sec_level,3,1}, {request_id,37078226,2147483647}]} Pdu: {pdu,report,2147483647,noError,0, [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** handle_snmp_report -> found corresponding request: reply to sync request Ref: #Ref<0.0.4.210> ModRef: #Ref<0.0.4.211> From: {<0.3.0>,#Ref<0.0.4.202>} *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** handle_snmp_pdu(get-response) -> Remaining: 4979 *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** handle_snmp_report -> deliver reply {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226,2147483647}],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]}}} *** [2016:09:08 21:26:00 831] Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" (from http://www.oid-info.com/) I have attached a wireshark trace for the snmp part of this exchange. I am invoking the snmpm module functions through a basic script as follows (using tips from the tutorial at https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) ......... .......... ok = application:start(crypto), ok = application:start(snmp), Userid = "snmp3user", Agent_target = "testagent", Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], Agent_ip = {xx,xxx,xxx,xxx}, Agent_port = 161 , Secure_name= Userid, Security_level = 'authPriv', Security_model = 'usm', Agent_version = 'v3', Auth_protocol = 'usmHMACSHAAuthProtocol', Priv_protocol = 'usmAesCfb128Protocol', % this is 16 in length Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), % this is 20 in length Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), ok = snmpm:register_user(Userid,snmpm_user_default,[]), ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ {auth, Auth_protocol}, {auth_key,Auth_key_local}, {priv, Priv_protocol}, {priv_key,Priv_key_local }, {sec_name, Secure_name} ]), ok = snmpm:register_agent(Userid, Agent_target ,[ {engine_id,Agent_engine_id}, {address, Agent_ip}, {port, Agent_port}, {version,Agent_version}, {sec_model,Security_model}, {sec_name,Secure_name}, {sec_level, Security_level} ]), Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), ........................ ........................ Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! Thanks, Devangana -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- No. Time Source Destination Protocol Length Info 1 2016-09-08 16:26:00.813592 xxxxxxxxxxxx xxxxxxxxxxxxx SNMP 182 encryptedPDU: privKey Unknown Frame 1: 182 bytes on wire (1456 bits), 182 bytes captured (1456 bits) Ethernet II, Src: Dell_5a:bb:91 (xxxxxxxxxxxxx), Dst: Cisco_ea:e8:00 (xxxxxxxxxxxxxxxx) Internet Protocol Version 4, Src: xxxxxxxxxxxx (xxxxxxxxxxxx), Dst: xxxxxxxxxxxxx (xxxxxxxxxxxxx) User Datagram Protocol, Src Port: commplex-main (5000), Dst Port: snmp (161) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 876803614 msgMaxSize: 484 msgFlags: 07 .... .1.. = Reportable: Set .... ..1. = Encrypted: Set .... ...1 = Authenticated: Set msgSecurityModel: USM (3) msgAuthoritativeEngineID: 800000080200001c42396cb0 1... .... = Engine ID Conformance: RFC3411 (SNMPv3) Engine Enterprise ID: ciscoSystems (9) Engine ID Format: MAC address (3) Engine ID Data: Cisco type: Agent (0x00) Engine ID Data: MAC address: Cisco_28:6c:b0 (00:1b:53:28:6c:b0) msgAuthoritativeEngineBoots: 0 msgAuthoritativeEngineTime: 0 msgUserName: snmp3user msgAuthenticationParameters: 55735044a3ef1173dfbd47d1 msgPrivacyParameters: 0000000000000001 msgData: encryptedPDU (1) encryptedPDU: 8044fe23c8fdcb813c4ec7b4c969d72a594e836044d5f872... ~ ======================= No. Time Source Destination Protocol Length Info 2 2016-09-08 16:26:00.825555 xxxxxxxxxxx xxxxxxxxxxx SNMP 170 report 1.3.6.1.6.3.15.1.1.2.0 Frame 2: 170 bytes on wire (1360 bits), 170 bytes captured (1360 bits) Ethernet II, Src: Cisco_ea:e8:00 (xxxxxxxxxxxxxx), Dst: Dell_5abb:91 (xxxxxxxxxxxx) Internet Protocol Version 4, Src: xxxxxxxxxxx (xxxxxxxxxxx), Dst: xxxxxxxxxxx (xxxxxxxxxxx) User Datagram Protocol, Src Port: snmp (161), Dst Port: commplex-main (5000) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 876803614 msgMaxSize: 1500 msgFlags: 01 .... .0.. = Reportable: Not set .... ..0. = Encrypted: Not set .... ...1 = Authenticated: Set msgSecurityModel: USM (3) msgAuthoritativeEngineID: 800000080200001c42396cb0 1... .... = Engine ID Conformance: RFC3411 (SNMPv3) Engine Enterprise ID: ciscoSystems (9) Engine ID Format: MAC address (3) Engine ID Data: Cisco type: Agent (0x00) Engine ID Data: MAC address: Cisco_28:6c:b0 (xxxxxxxxxxxxxx) msgAuthoritativeEngineBoots: 3 msgAuthoritativeEngineTime: 57632386 msgUserName: snmp3user msgAuthenticationParameters: 6606b8b6f7fc4e85c9c9dbb6 msgPrivacyParameters: msgData: plaintext (0) plaintext contextEngineID: 800000080200001c42396cb0 1... .... = Engine ID Conformance: RFC3411 (SNMPv3) Engine Enterprise ID: ciscoSystems (9) Engine ID Format: MAC address (3) Engine ID Data: Cisco type: Agent (0x00) Engine ID Data: MAC address: Cisco_28:6c:b0 (xxxxxxxxxxxxxxx) contextName: data: report (8) report request-id: 2147483647 error-status: noError (0) error-index: 0 variable-bindings: 1 item 1.3.6.1.6.3.15.1.1.2.0: 33 Object Name: 1.3.6.1.6.3.15.1.1.2.0 (iso.3.6.1.6.3.15.1.1.2.0) Value (Counter32): 33 From kennethlakin@REDACTED Sat Sep 10 06:58:21 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Fri, 9 Sep 2016 21:58:21 -0700 Subject: [erlang-questions] gen_statem next_event queue question Message-ID: <9b604755-8318-168e-94b0-898933696a12@gmail.com> Okay, I've looked over the gen_statem documentation a few times and have not found a way to do what I'm looking to do. Consider the following (poorly described) scenario: My gen_statem is a state_functions gen_statem that's in state 'one'. It does some work, and then returns {next_state, one, State, [{next_event, internal, e_one}, {next_event, internal, e_two}]} The intent here is that we immediately want to process event e_one, and then immediately process event e_two. So, state 'one' is called again with the event e_one. It does some work and determines that it needs to work on e_three after the pending event queue is drained. (That is, once e_two has been worked on.) If I return {next_state, one, State, [{next_event, internal, e_three}]} then 'one' will next be called with the event e_three, right? If that's right, then is there a way to add events to the tail of the queue, rather than the head? Thanks much in advance. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dmytro.lytovchenko@REDACTED Sat Sep 10 12:59:36 2016 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Sat, 10 Sep 2016 10:59:36 +0000 Subject: [erlang-questions] Trace erlang BIFs with dbg In-Reply-To: References: Message-ID: There is a known problem observed in unreleased Erlang R20, that I am working to have fixed soon, and the sympthoms are that some BIFs do not send trace messages for returns and exceptions. Some other BIFs do, though. I can not say when this problem appeared first, but it could be present in R19. Possibly related to recent changes in tracing. This is fundamental problem (SOME execution paths of some BIFs do not have trace checks/reports in them), and i am on it. l?r 10 sep. 2016 kl 00:38 skrev nato : > Are BIFs such as `length/1` part of the erlang module, or do BIFs live > somewhere else then get masqueraded ... > > I am trying to trace functions like these with dbg, and nothing is yielded. > For example, I am trying the following with no success... > > 1> dbg:tracer(), dbg:p(all, c). > 2> dbg:tpl(erlang, length, x). > 3> erlang:length( [] ). %% or simply `length([]).` > > Or, are my above dbg flags leaving the erlang module out... or... confused. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik_pawlak@REDACTED Sun Sep 11 01:09:09 2016 From: dominik_pawlak@REDACTED (Dominik Pawlak) Date: Sun, 11 Sep 2016 01:09:09 +0200 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: Message-ID: Hello Devangana, Basically, you just have to perform the sync_get once more. I observed similar behavior in OTP 17.1 (snmp 4.25.1). The first request will always fail because the manager is not fully configured to communicate with the agent (more on that below). A longer explanation: In snmp v3 there is a process called 'discovery', which should be performed before secure communication with the agent can be established. It is described here: https://tools.ietf.org/html/rfc3414#section-4 The snmp library in OTP does not implement that process (at least not as described in the RFC). This process has two steps: 'snmpEngineID discovery' and 'time synchronization'. The first step is skipped altogether in OTP - you have to provide engine id upfront. The second step is performed by the first request - it will always fail with the 'usmStatsNotInTimeWindows' error report message, but it will set the required 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' in the manager. Best, Dominik On 10.09.2016 06:48, Devangana Tarafdar wrote: > Hello, > > I am trying to connect to a third party SNMP agent, using snmp manager > (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running into > a problem where the agent is returning this error on the manager > calling sync_get: > > > *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** > handle_snmp_report -> entry with > Domain: snmpUDPDomain > Addr: {{xx,xxx,xxx,xxx},161} > ReqId: 37078226 > Rep: {invalid_sec_info,[{sec_level,3,1}, > {request_id,37078226,2147483647}]} > Pdu: {pdu,report,2147483647,noError,0, > [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} > *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** > handle_snmp_report -> found corresponding request: > reply to sync request > Ref: #Ref<0.0.4.210> > ModRef: #Ref<0.0.4.211> > From: {<0.3.0>,#Ref<0.0.4.202>} > *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** > handle_snmp_pdu(get-response) -> Remaining: 4979 > *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** > handle_snmp_report -> deliver reply > > {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226,2147483647}],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]}}} > > *** [2016:09:08 21:26:00 831] > > Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" > (from http://www.oid-info.com/) > > I have attached a wireshark trace for the snmp part of this exchange. > > I am invoking the snmpm module functions through a basic script as > follows (using tips from the tutorial at > https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) > ......... > .......... > ok = application:start(crypto), > ok = application:start(snmp), > > Userid = "snmp3user", > Agent_target = "testagent", > Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], > Agent_ip = {xx,xxx,xxx,xxx}, > Agent_port = 161 , > Secure_name= Userid, > > Security_level = 'authPriv', > Security_model = 'usm', > Agent_version = 'v3', > Auth_protocol = 'usmHMACSHAAuthProtocol', > Priv_protocol = 'usmAesCfb128Protocol', > > % this is 16 in length > Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), > > % this is 20 in length > Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), > > ok = snmpm:register_user(Userid,snmpm_user_default,[]), > ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ > {auth, Auth_protocol}, > {auth_key,Auth_key_local}, > {priv, Priv_protocol}, > {priv_key,Priv_key_local }, > {sec_name, Secure_name} > ]), > ok = snmpm:register_agent(Userid, Agent_target ,[ > {engine_id,Agent_engine_id}, > {address, Agent_ip}, > {port, Agent_port}, > {version,Agent_version}, > {sec_model,Security_model}, > {sec_name,Secure_name}, > {sec_level, Security_level} > ]), > Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), > ........................ > ........................ > Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! > > > Thanks, > Devangana > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Sun Sep 11 06:16:20 2016 From: sdl.web@REDACTED (Leo Liu) Date: Sun, 11 Sep 2016 12:16:20 +0800 Subject: [erlang-questions] Erlang/OTP libraries/modules replaced by third party projects References: <1473263856.3030071.718552769.44285A4B@webmail.messagingengine.com> Message-ID: On 2016-09-07 08:57 -0700, Tristan Sloughter wrote: > Please comment on this gist or reply to this email: > https://gist.github.com/tsloughter/4d18c474f009dd3a3eeb094f8933e90b I find this interesting and informative however it is hard to assess some of the information provided. For example, "eldap support is poor, the app isn't even proper OTP" I wonder if this is a deliberate decision to go this way. Any ideas? Leo From nayibor@REDACTED Sun Sep 11 08:56:55 2016 From: nayibor@REDACTED (Nuku Ameyibor) Date: Sun, 11 Sep 2016 06:56:55 +0000 Subject: [erlang-questions] Execute module code from stored anonymous function Message-ID: Dear List , i run into an issue where i was storing an anonymous function in mnesia to be executed later . *F=fun(test) ->mprocess:process_template(test)end.* however as soon as i make some changes to the mprocess module and upgrade the module i get a *** exception error: bad function* error when i retrieve the fun and try to execute which i assume is because of the difference in the module versions . Is there a way of making the stored fun execute the code and not have version conflicts . -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmytro.lytovchenko@REDACTED Sun Sep 11 09:08:27 2016 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Sun, 11 Sep 2016 07:08:27 +0000 Subject: [erlang-questions] Execute module code from stored anonymous function In-Reply-To: References: Message-ID: In your case the pointer to function is stored internally and it goes extinct when module is gone. If you make it calculate function at runtime by, say, calling apply(mprocess, process_template, [test]), then it should work. s?n 11 sep. 2016 kl 08:57 skrev Nuku Ameyibor : > Dear List , > > i run into an issue where i was storing an anonymous function in mnesia > to be executed later . > *F=fun(test) ->mprocess:process_template(test)end.* > > > however as soon as i make some changes to the mprocess module and > upgrade the module i get a *** exception error: bad function* error when > i retrieve the fun and try to execute which i assume is because of the > difference in the module versions . > Is there a way of making the stored fun execute the code and not have > version conflicts . > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nayibor@REDACTED Sun Sep 11 09:27:33 2016 From: nayibor@REDACTED (Nuku Ameyibor) Date: Sun, 11 Sep 2016 07:27:33 +0000 Subject: [erlang-questions] Execute module code from stored anonymous function In-Reply-To: References: Message-ID: thanks for quick reply . will give it a shot . On Sun, Sep 11, 2016 at 7:08 AM, Dmytro Lytovchenko < dmytro.lytovchenko@REDACTED> wrote: > In your case the pointer to function is stored internally and it goes > extinct when module is gone. > If you make it calculate function at runtime by, say, calling > apply(mprocess, process_template, [test]), then it should work. > > s?n 11 sep. 2016 kl 08:57 skrev Nuku Ameyibor : > >> Dear List , >> >> i run into an issue where i was storing an anonymous function in mnesia >> to be executed later . >> *F=fun(test) ->mprocess:process_template(test)end.* >> >> >> however as soon as i make some changes to the mprocess module and >> upgrade the module i get a *** exception error: bad function* error when >> i retrieve the fun and try to execute which i assume is because of the >> difference in the module versions . >> Is there a way of making the stored fun execute the code and not have >> version conflicts . >> >> _______________________________________________ >> 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 Sun Sep 11 10:27:59 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 11 Sep 2016 10:27:59 +0200 Subject: [erlang-questions] Erlang/OTP libraries/modules replaced by third party projects In-Reply-To: References: <1473263856.3030071.718552769.44285A4B@webmail.messagingengine.com> Message-ID: On Sun, Sep 11, 2016 at 6:16 AM, Leo Liu wrote: > eldap support is poor, the app isn't even proper OTP "Isn't proper OTP" is often code-speak for "doesn't work well under failure" or "the failure mode isn't handled". In other words, the system works well until failure, and then it starts becoming fragile. In 'eldap's case, opening a connection spawn_link/1's a worker process and ties it to the current process. A more OTP-like approach would have been to use 'proc_lib' to make the spawned process adhere to the OTP design principles, but perhaps there isn't a need for it to do so. Tobbe is no newcomer to Erlang and he generally knows what he is doing, so chances are he had good reason to handle the problem as he does. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Sun Sep 11 10:39:06 2016 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Sun, 11 Sep 2016 10:39:06 +0200 Subject: [erlang-questions] Execute module code from stored anonymous function In-Reply-To: References: Message-ID: > In your case the pointer to function is stored internally and it goes extinct when module is gone. Why is this the behavior? I would expect the fun to properly call the latest version of the module's code if not purged, throwing an exception otherwise, not "just throw because version changed". Why disallow funs to directly reference version-changing code? (indirectly because fun () -> apply(M, F, A) end is still possible) I am surprised & interested in the reasons behind having * fun () -> mod:fname(Arg1, Arg2, ...) end * fun () -> erlang:apply(mod, fname, [Arg1, Arg2, ...]) end be semantically different! Cheers, -- Pierre Fenoll On 11 September 2016 at 09:27, Nuku Ameyibor wrote: > thanks for quick reply . > will give it a shot . > > On Sun, Sep 11, 2016 at 7:08 AM, Dmytro Lytovchenko < > dmytro.lytovchenko@REDACTED> wrote: > >> In your case the pointer to function is stored internally and it goes >> extinct when module is gone. >> If you make it calculate function at runtime by, say, calling >> apply(mprocess, process_template, [test]), then it should work. >> >> s?n 11 sep. 2016 kl 08:57 skrev Nuku Ameyibor : >> >>> Dear List , >>> >>> i run into an issue where i was storing an anonymous function in mnesia >>> to be executed later . >>> *F=fun(test) ->mprocess:process_template(test)end.* >>> >>> >>> however as soon as i make some changes to the mprocess module and >>> upgrade the module i get a *** exception error: bad function* error >>> when i retrieve the fun and try to execute which i assume is because of the >>> difference in the module versions . >>> Is there a way of making the stored fun execute the code and not have >>> version conflicts . >>> >>> _______________________________________________ >>> 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 tony@REDACTED Sun Sep 11 13:39:33 2016 From: tony@REDACTED (Tony Rogvall) Date: Sun, 11 Sep 2016 13:39:33 +0200 Subject: [erlang-questions] Execute module code from stored anonymous function In-Reply-To: References: Message-ID: A local fun ?belongs? to the code module where it is defined. So the problem is that the definition it self is purged out of the system. This is not the case with fun mod:fun/a, for example fun erlang:integer_to_list/1 is just referring to an export entry. You can still use fun?s to refer to the old version of the definition ( in the old module ) as long as they are not purged. I some time use this fact to create transaction funs that survive ONE code reload while executing for example rules that are compiled. The example below let you create a global ets store for procedures. > etsfun:create(). > etsfun:store_procedure(f, etsfun:procedure_global1()). > etsfun:call_procesure(f, 1). ?1? In this case you reload the ?etsfun? module as many time as you like since, the global1 function is not defined in the etsfun module. > etsfun:create(). > etsfun:store_procedure(f, etsfun:procedure_global2()). > etsfun:call_procedure(f, 1). ?1? If you just recompile+reload this module without changing anything that will allow you to reload any number of times as well. But if you change the module a tine bit by for example adding a blank in a string ( must be in code ) then you can still call the function since the old version is still there. But change code one more recompile+reload and the original fun is purged from the system and the call will crash, as expected. This last example with a local function that talks a bit, show this a bit more. > etsfun:create(). > etsfun:store_procedure(f, etsfun:procedure_local()). > etsfun:call_procedure(f, 1). fun 1 Now change the body of the procedure_local() to the one with ?hej? and recompile/reload once. > etsfun:call_procedure(f, 1). fun 1 Same result, the same fun. But if you change again and recompile/reload this will crash. and finally > etsfun:store_procedure(f, etsfun:procedure_local()). > etsfun:call_procedure(f, 1). hej 1 and the new definition is stored. -module(etsfun). -compile(export_all). create() -> ets:new(etsfun, [named_table, public]). store_procedure(Key, F) -> ets:insert(etsfun, {Key,F}). call_procedure(Key,Arg) -> [{_,F}] = ets:lookup(etsfun, Key), F(Arg). procedure_global1() -> fun erlang:integer_to_list/1. procedure_global2() -> fun(X) -> erlang:integer_to_list(X) end. procedure_local() -> fun(X) -> my_local_func(X) end. %% my_local_func(X) -> io:format("hej ~w\n", [X]). my_local_func(X) -> io:format("fun ~w\n", [X]). > On 11 sep 2016, at 10:39, Pierre Fenoll wrote: > > > In your case the pointer to function is stored internally and it goes extinct when module is gone. > > Why is this the behavior? I would expect the fun to properly call the latest version of the module's code if not purged, > throwing an exception otherwise, not "just throw because version changed". > > Why disallow funs to directly reference version-changing code? > (indirectly because fun () -> apply(M, F, A) end is still possible) > > > I am surprised & interested in the reasons behind having > > * fun () -> mod:fname(Arg1, Arg2, ...) end > * fun () -> erlang:apply(mod, fname, [Arg1, Arg2, ...]) end > > be semantically different! > > > > Cheers, > -- > Pierre Fenoll > > > On 11 September 2016 at 09:27, Nuku Ameyibor wrote: > thanks for quick reply . > will give it a shot . > > > On Sun, Sep 11, 2016 at 7:08 AM, Dmytro Lytovchenko wrote: > In your case the pointer to function is stored internally and it goes extinct when module is gone. > If you make it calculate function at runtime by, say, calling apply(mprocess, process_template, [test]), then it should work. > > s?n 11 sep. 2016 kl 08:57 skrev Nuku Ameyibor : > Dear List , > > i run into an issue where i was storing an anonymous function in mnesia to be executed later . > F=fun(test) ->mprocess:process_template(test)end. > > > however as soon as i make some changes to the mprocess module and upgrade the module i get a ** exception error: bad function error when i retrieve the fun and try to execute which i assume is because of the difference in the module versions . > Is there a way of making the stored fun execute the code and not have version conflicts . > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From devangana@REDACTED Sun Sep 11 16:46:30 2016 From: devangana@REDACTED (Devangana Tarafdar) Date: Sun, 11 Sep 2016 09:46:30 -0500 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: Message-ID: Hello Dominik, Thanks you for the reply. I sent another sync_get after the first as you suggested. The wireshark trace shows the manager has updated the 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' to the values sent by the Agent as you pointed out. But now the agent does not respond at all and the sync_get fails with a timeout. I tried adding a second's sleep between the 2 gets as well. I don't have access currently to the agent's logs or configuration but have you seen this before ? Thanks ! Devangana On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak wrote: > Hello Devangana, > Basically, you just have to perform the sync_get once more. I observed > similar behavior in OTP 17.1 (snmp 4.25.1). The first request will always > fail because the manager is not fully configured to communicate with the > agent (more on that below). > > A longer explanation: > > In snmp v3 there is a process called 'discovery', which should be > performed before secure communication with the agent can be established. It > is described here: > > https://tools.ietf.org/html/rfc3414#section-4 > > The snmp library in OTP does not implement that process (at least not as > described in the RFC). > This process has two steps: 'snmpEngineID discovery' and 'time > synchronization'. > The first step is skipped altogether in OTP - you have to provide engine > id upfront. > The second step is performed by the first request - it will always fail > with the 'usmStatsNotInTimeWindows' error report message, but it will set > the required 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' > in the manager. > > Best, > Dominik > > > On 10.09.2016 06:48, Devangana Tarafdar wrote: > > Hello, > > I am trying to connect to a third party SNMP agent, using snmp manager > (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running into a > problem where the agent is returning this error on the manager calling > sync_get: > > > *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** > handle_snmp_report -> entry with > Domain: snmpUDPDomain > Addr: {{xx,xxx,xxx,xxx},161} > ReqId: 37078226 > Rep: {invalid_sec_info,[{sec_level,3,1}, > {request_id,37078226,2147483647}]} > Pdu: {pdu,report,2147483647,noError,0, > [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} > *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** > handle_snmp_report -> found corresponding request: > reply to sync request > Ref: #Ref<0.0.4.210> > ModRef: #Ref<0.0.4.211> > From: {<0.3.0>,#Ref<0.0.4.202>} > *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** > handle_snmp_pdu(get-response) -> Remaining: 4979 > *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** > handle_snmp_report -> deliver reply > > {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226,2147483647 > }],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]}}} > > *** [2016:09:08 21:26:00 831] > > Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" (from > http://www.oid-info.com/) > > I have attached a wireshark trace for the snmp part of this exchange. > > I am invoking the snmpm module functions through a basic script as follows > (using tips from the tutorial at > https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) > ......... > .......... > > ok = application:start(crypto), > ok = application:start(snmp), > > Userid = "snmp3user", > Agent_target = "testagent", > Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], > Agent_ip = {xx,xxx,xxx,xxx}, > Agent_port = 161 , > Secure_name= Userid, > > Security_level = 'authPriv', > Security_model = 'usm', > Agent_version = 'v3', > Auth_protocol = 'usmHMACSHAAuthProtocol', > Priv_protocol = 'usmAesCfb128Protocol', > > % this is 16 in length > Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), > > % this is 20 in length > Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), > > ok = snmpm:register_user(Userid,snmpm_user_default,[]), > > ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ > {auth, Auth_protocol}, > {auth_key,Auth_key_local}, > {priv, Priv_protocol}, > {priv_key,Priv_key_local }, > {sec_name, Secure_name} > ]), > ok = snmpm:register_agent(Userid, Agent_target ,[ > {engine_id,Agent_engine_id}, > {address, Agent_ip}, > {port, Agent_port}, > {version,Agent_version}, > {sec_model,Security_model}, > {sec_name,Secure_name}, > {sec_level, Security_level} > > ]), > Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), ........................ > > ........................ > > Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! > > > > Thanks, > Devangana > > > > > > > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.kachanovskiy@REDACTED Sun Sep 11 17:38:00 2016 From: sergey.kachanovskiy@REDACTED (Sergey Kachanovskiy) Date: Sun, 11 Sep 2016 17:38:00 +0200 Subject: [erlang-questions] building OTP with OpenSSL 1.1.0 Message-ID: An HTML attachment was scrubbed... URL: From dominik_pawlak@REDACTED Sun Sep 11 22:08:00 2016 From: dominik_pawlak@REDACTED (Dominik Pawlak) Date: Sun, 11 Sep 2016 22:08:00 +0200 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: Message-ID: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> Hello Devangana, Hard to tell, but I see that you haven't specified any context in your sync_get. Are you sure it is not needed? I would also double check the engine id and security configuration. Have you managed to connect to that agent from something other than OTP (say snmpb, snmpget)? If so, you can compare in Wireshark, the snmp requests from erlang and from that tool. You can even enter your snmp credentials in Wireshark and it will decode encrypted messages. I hope any of this helps. Best Dominik On 11.09.2016 16:46, Devangana Tarafdar wrote: > Hello Dominik, > > Thanks you for the reply. > > I sent another sync_get after the first as you suggested. The > wireshark trace shows the manager has updated the > 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' to the > values sent by the Agent as you pointed out. But now the agent does > not respond at all and the sync_get fails with a timeout. I tried > adding a second's sleep between the 2 gets as well. I don't have > access currently to the agent's logs or configuration but have you > seen this before ? > > Thanks ! > Devangana > > > On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak > > wrote: > > Hello Devangana, > Basically, you just have to perform the sync_get once more. I > observed similar behavior in OTP 17.1 (snmp 4.25.1). The first > request will always fail because the manager is not fully > configured to communicate with the agent (more on that below). > > A longer explanation: > > In snmp v3 there is a process called 'discovery', which should be > performed before secure communication with the agent can be > established. It is described here: > > https://tools.ietf.org/html/rfc3414#section-4 > > > The snmp library in OTP does not implement that process (at least > not as described in the RFC). > This process has two steps: 'snmpEngineID discovery' and 'time > synchronization'. > The first step is skipped altogether in OTP - you have to provide > engine id upfront. > The second step is performed by the first request - it will always > fail with the 'usmStatsNotInTimeWindows' error report message, but > it will set the required 'msgAuthoritativeEngineBoots' and > 'msgAuthoritativeEngineTime' in the manager. > > Best, > Dominik > > > On 10.09.2016 06:48, Devangana Tarafdar wrote: >> Hello, >> >> I am trying to connect to a third party SNMP agent, using snmp >> manager (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am >> running into a problem where the agent is returning this error on >> the manager calling sync_get: >> >> >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >> handle_snmp_report -> entry with >> Domain: snmpUDPDomain >> Addr: {{xx,xxx,xxx,xxx},161} >> ReqId: 37078226 >> Rep: {invalid_sec_info,[{sec_level,3,1}, >> {request_id,37078226,2147483647 }]} >> Pdu: {pdu,report,2147483647 ,noError,0, >> [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** >> handle_snmp_report -> found corresponding request: >> reply to sync request >> Ref: #Ref<0.0.4.210> >> ModRef: #Ref<0.0.4.211> >> From: {<0.3.0>,#Ref<0.0.4.202>} >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >> handle_snmp_pdu(get-response) -> Remaining: 4979 >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >> handle_snmp_report -> deliver reply >> >> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226,2147483647 >> }],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]}}} >> >> *** [2016:09:08 21:26:00 831] >> >> Where [1,3,6,1,6,3,15,1,1,2,0] maps to >> "usmStatsNotInTimeWindows" (from http://www.oid-info.com/) >> >> I have attached a wireshark trace for the snmp part of this >> exchange. >> >> I am invoking the snmpm module functions through a basic script >> as follows (using tips from the tutorial at >> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start >> ) >> ......... >> .......... >> ok = application:start(crypto), >> ok = application:start(snmp), >> >> Userid = "snmp3user", >> Agent_target = "testagent", >> Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], >> Agent_ip = {xx,xxx,xxx,xxx}, >> Agent_port = 161 , >> Secure_name= Userid, >> >> Security_level = 'authPriv', >> Security_model = 'usm', >> Agent_version = 'v3', >> Auth_protocol = 'usmHMACSHAAuthProtocol', >> Priv_protocol = 'usmAesCfb128Protocol', >> >> % this is 16 in length >> Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), >> >> % this is 20 in length >> Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), >> >> ok = snmpm:register_user(Userid,snmpm_user_default,[]), >> ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ >> {auth, Auth_protocol}, >> {auth_key,Auth_key_local}, >> {priv, Priv_protocol}, >> {priv_key,Priv_key_local }, >> {sec_name, Secure_name} >> ]), >> ok = snmpm:register_agent(Userid, Agent_target ,[ >> {engine_id,Agent_engine_id}, >> {address, Agent_ip}, >> {port, Agent_port}, >> {version,Agent_version}, >> {sec_model,Security_model}, >> {sec_name,Secure_name}, >> {sec_level, Security_level} >> ]), >> Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), >> ........................ >> ........................ >> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! >> Thanks, Devangana >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From devangana@REDACTED Sun Sep 11 23:09:47 2016 From: devangana@REDACTED (Devangana Tarafdar) Date: Sun, 11 Sep 2016 16:09:47 -0500 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> References: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> Message-ID: Hi Dominik, I have not looked into the context. Will check all the items that you mention. I have been able to connect to the agent using snmpwalk and snmpget though I have not studied the wireshark output of those in detail. Thanks again for all these tips and I will get back to you . Devangana On Sep 11, 2016 3:08 PM, "Dominik Pawlak" wrote: > Hello Devangana, > Hard to tell, but I see that you haven't specified any context in your > sync_get. Are you sure it is not needed? I would also double check the > engine id and security configuration. > Have you managed to connect to that agent from something other than OTP > (say snmpb, snmpget)? > If so, you can compare in Wireshark, the snmp requests from erlang and > from that tool. You can even enter your snmp credentials in Wireshark and > it will decode encrypted messages. > I hope any of this helps. > > Best > Dominik > > On 11.09.2016 16:46, Devangana Tarafdar wrote: > > Hello Dominik, > > Thanks you for the reply. > > I sent another sync_get after the first as you suggested. The wireshark > trace shows the manager has updated the 'msgAuthoritativeEngineBoots' and > 'msgAuthoritativeEngineTime' to the values sent by the Agent as you pointed > out. But now the agent does not respond at all and the sync_get fails with > a timeout. I tried adding a second's sleep between the 2 gets as well. I > don't have access currently to the agent's logs or configuration but have > you seen this before ? > > Thanks ! > Devangana > > > On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak < > dominik_pawlak@REDACTED> wrote: > >> Hello Devangana, >> Basically, you just have to perform the sync_get once more. I observed >> similar behavior in OTP 17.1 (snmp 4.25.1). The first request will always >> fail because the manager is not fully configured to communicate with the >> agent (more on that below). >> >> A longer explanation: >> >> In snmp v3 there is a process called 'discovery', which should be >> performed before secure communication with the agent can be established. It >> is described here: >> >> https://tools.ietf.org/html/rfc3414#section-4 >> >> The snmp library in OTP does not implement that process (at least not as >> described in the RFC). >> This process has two steps: 'snmpEngineID discovery' and 'time >> synchronization'. >> The first step is skipped altogether in OTP - you have to provide engine >> id upfront. >> The second step is performed by the first request - it will always fail >> with the 'usmStatsNotInTimeWindows' error report message, but it will set >> the required 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' >> in the manager. >> >> Best, >> Dominik >> >> >> On 10.09.2016 06:48, Devangana Tarafdar wrote: >> >> Hello, >> >> I am trying to connect to a third party SNMP agent, using snmp manager >> (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running into a >> problem where the agent is returning this error on the manager calling >> sync_get: >> >> >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >> handle_snmp_report -> entry with >> Domain: snmpUDPDomain >> Addr: {{xx,xxx,xxx,xxx},161} >> ReqId: 37078226 >> Rep: {invalid_sec_info,[{sec_level,3,1}, >> {request_id,37078226,2147483647}]} >> Pdu: {pdu,report,2147483647,noError,0, >> [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** >> handle_snmp_report -> found corresponding request: >> reply to sync request >> Ref: #Ref<0.0.4.210> >> ModRef: #Ref<0.0.4.211> >> From: {<0.3.0>,#Ref<0.0.4.202>} >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >> handle_snmp_pdu(get-response) -> Remaining: 4979 >> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >> handle_snmp_report -> deliver reply >> >> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226,2147483647 >> }],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]}}} >> >> *** [2016:09:08 21:26:00 831] >> >> Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" (from >> http://www.oid-info.com/) >> >> I have attached a wireshark trace for the snmp part of this exchange. >> >> I am invoking the snmpm module functions through a basic script as >> follows (using tips from the tutorial at >> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) >> ......... >> .......... >> >> ok = application:start(crypto), >> ok = application:start(snmp), >> >> Userid = "snmp3user", >> Agent_target = "testagent", >> Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], >> Agent_ip = {xx,xxx,xxx,xxx}, >> Agent_port = 161 , >> Secure_name= Userid, >> >> Security_level = 'authPriv', >> Security_model = 'usm', >> Agent_version = 'v3', >> Auth_protocol = 'usmHMACSHAAuthProtocol', >> Priv_protocol = 'usmAesCfb128Protocol', >> >> % this is 16 in length >> Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), >> >> % this is 20 in length >> Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), >> >> ok = snmpm:register_user(Userid,snmpm_user_default,[]), >> >> ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ >> {auth, Auth_protocol}, >> {auth_key,Auth_key_local}, >> {priv, Priv_protocol}, >> {priv_key,Priv_key_local }, >> {sec_name, Secure_name} >> ]), >> ok = snmpm:register_agent(Userid, Agent_target ,[ >> {engine_id,Agent_engine_id}, >> {address, Agent_ip}, >> {port, Agent_port}, >> {version,Agent_version}, >> {sec_model,Security_model}, >> {sec_name,Secure_name}, >> {sec_level, Security_level} >> >> ]), >> Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), ........................ >> >> ........................ >> >> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! >> >> Thanks, Devangana >> >> _______________________________________________ >> erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Mon Sep 12 09:18:23 2016 From: aschultz@REDACTED (Andreas Schultz) Date: Mon, 12 Sep 2016 09:18:23 +0200 (CEST) Subject: [erlang-questions] building OTP with OpenSSL 1.1.0 In-Reply-To: References: Message-ID: <1838680328.28855.1473664703829.JavaMail.zimbra@tpip.net> Hi Sergey, > From: "Sergey Kachanovskiy" > To: erlang-questions@REDACTED > Sent: Sunday, September 11, 2016 5:38:00 PM > Subject: [erlang-questions] building OTP with OpenSSL 1.1.0 > Good day everyone, > just trying to build 19.0.5 (and then 18.3.4.4 - as PoC) against OpenSSL 1.1.0 > (released recently), and it doesn't build for me. Did anyone have luck with > such excercise? > platform is Ubuntu 16.04.1, if that matters... > here's what I see: > 1) 1.1.0 does seem to have Kerberos5 support removed, hence configure, checking > whether OpenSSL has KRB5 support enabled and doing it by relying on a fact that > in case of no such support OPENSSL_NO_KRB5 is going to be defined (assuming > this symbol not being defined means KRB5 support is enabled), sees no such > symbol, and wrongly assumes there's KRB5 support compiled into OpenSSL, and > looks for krb5.h in "known locations", does not find it there, and disables > crypto/ssl/ssh applications. An ifndef changed to ifdef in erts/configure > around line 22590 is a quick fix to let it continue. > 2) OTP's lib/crypto/c_src/crypto.c wants "openssl/chacha.h" and > "openssl/poly1305.h". which do not exist in OpenSSL 1.1.0 source. There are > chacha.h and poly1305.h in crypto/include/internal, but they don't seem to be > what OTP's crypto.c wants, as they don't contain required functions (like > CRYPTO_chacha_20, for example)...1.0.2h, the last of OpenSSL's 1.0.x versions, > simply does not have support for Chacha20/Poly1305, hence OTP compiles ok. > what looks promising is BoringSSL (from Google) and LibreSSL, both seem to have > required functions, but I wasn't able to find any signs of OTP built/tested > against anything except OpenSSL. What do you use for SSL to build your OTP, > please? Is use of LibreSSL/BoringSSL supported for OTP? I did the original test for chacha with LibreSSL. At that time, openssl did not have any the required headers. When they decided to add ChaCha, they only added the EVP interface for it and left the other methods as privates. So, for the moment, if you want working ChaCha20/Poly1305 support, you have to use LibreSSL. For the future, someone has to port the ChaCha20 function for the EVP interface for them to work. Andreas > As always, crossing fingers I simply missed some small point and/or did > something wrong, and everything works, and someone's just gonna point me out my > mistakes :) > Thanks. > Best regards, > Sergey. > _______________________________________________ > 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 Mon Sep 12 10:20:50 2016 From: garazdawi@REDACTED (Lukas Larsson) Date: Mon, 12 Sep 2016 10:20:50 +0200 Subject: [erlang-questions] Trace erlang BIFs with dbg In-Reply-To: References: Message-ID: Hello, It is not possible to trace on what is called "guard bifs", i.e. functions in the erlang module that can be used in guards. For a full list of which those function are see: http://erlang.org/doc/reference_manual/expressions.html#id84459. Lukas On Fri, Sep 9, 2016 at 11:56 PM, nato wrote: > Are BIFs such as `length/1` part of the erlang module, or do BIFs live > somewhere else then get masqueraded ... > > I am trying to trace functions like these with dbg, and nothing is yielded. > For example, I am trying the following with no success... > > 1> dbg:tracer(), dbg:p(all, c). > 2> dbg:tpl(erlang, length, x). > 3> erlang:length( [] ). %% or simply `length([]).` > > Or, are my above dbg flags leaving the erlang module out... or... confused. > _______________________________________________ > 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 Mon Sep 12 11:28:30 2016 From: ingela.andin@REDACTED (Ingela Andin) Date: Mon, 12 Sep 2016 11:28:30 +0200 Subject: [erlang-questions] Erlang/OTP libraries/modules replaced by third party projects In-Reply-To: References: <1473263856.3030071.718552769.44285A4B@webmail.messagingengine.com> Message-ID: Hi! 2016-09-11 6:16 GMT+02:00 Leo Liu : > On 2016-09-07 08:57 -0700, Tristan Sloughter wrote: > > Please comment on this gist or reply to this email: > > https://gist.github.com/tsloughter/4d18c474f009dd3a3eeb094f8933e90b > > I find this interesting and informative however it is hard to assess > some of the information provided. > > For example, > > "eldap support is poor, the app isn't even proper OTP" > > I wonder if this is a deliberate decision to go this way. Any ideas? > > This is a symptom of that the OTP team have not had a good enough process for including contributions. I think it is just lately that PR-process has started to work good enough. In the past it was quite common that prototypes that work well for some use case where included without proper tests, documentation or code reviews. We do have it in our backlog to make eldap into a proper OTP application, it just has not been prioritized high enough yet. PR are welcome. Regards Ingela Erlang/OTP Team - Ericsson AB > Leo > > _______________________________________________ > 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 Mon Sep 12 12:07:27 2016 From: ingela.andin@REDACTED (Ingela Andin) Date: Mon, 12 Sep 2016 12:07:27 +0200 Subject: [erlang-questions] gen_statem next_event queue question In-Reply-To: <9b604755-8318-168e-94b0-898933696a12@gmail.com> References: <9b604755-8318-168e-94b0-898933696a12@gmail.com> Message-ID: Hi!i! 2016-09-10 6:58 GMT+02:00 Kenneth Lakin : > Okay, I've looked over the gen_statem documentation a few times and have > not found a way to do what I'm looking to do. Consider the following > (poorly described) scenario: > > My gen_statem is a state_functions gen_statem that's in state 'one'. > It does some work, and then returns > {next_state, one, State, [{next_event, internal, e_one}, {next_event, > internal, e_two}]} > > The intent here is that we immediately want to process event e_one, and > then immediately process event e_two. > > So, state 'one' is called again with the event e_one. > It does some work and determines that it needs to work on e_three after > the pending event queue is drained. (That is, once e_two has been worked > on.) If I return > {next_state, one, State, [{next_event, internal, e_three}]} > then 'one' will next be called with the event e_three, right? > > If that's right, then is there a way to add events to the tail of the > queue, rather than the head? > > Thanks much in advance. > > If you send an event to yourself (gen_statem:call/cast or !) it will end up last in in the queue. The next_event is to make sure this event will be handled next, before other events that may have been received from outside of the gen_statem processes control during the handling of the last event. It is very useful in some cases in others you might not be at all interested in having internal events. Regards Ingela Erlang OTP/Team - Ericsson AB > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Mon Sep 12 12:23:58 2016 From: bchesneau@REDACTED (Benoit Chesneau) Date: Mon, 12 Sep 2016 10:23:58 +0000 Subject: [erlang-questions] reorder SSL certificate chain with Erlang 19 Message-ID: Is there anyway now to reorder the certificate chain received with Erlang 19 like browsers and most languages do by default. Maybe in an hackish way? It's actually the cause of many connection issue via http to some servers and the response can't just be about asking the server owner to fix it. Users expect that the connection will work as it is with curl. Any hint is appreciated :) - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Mon Sep 12 13:23:10 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Mon, 12 Sep 2016 04:23:10 -0700 Subject: [erlang-questions] gen_statem next_event queue question In-Reply-To: References: <9b604755-8318-168e-94b0-898933696a12@gmail.com> Message-ID: On 09/12/2016 03:07 AM, Ingela Andin wrote: > If you send an event to yourself (gen_statem:call/cast or !) it will end up > last in in the queue. Sorry, I should have been more clear in my initial message. It seems to me that -conceptually- gen_statem has three queues: * The next_event queue (which actually seems to behave like a stack) * The "postpone" queue (which -I think- gets put at the front of the next_event queue (but _after_ any {next_event...} actions passed along in the state transition tuple) on state machine state change) * The regular process mailbox Is this wildly incorrect? If my understanding is correct, then call/cast/! will put the message at the tail of the process mailbox, yes? Additionally, does gen_statem provide the tools to put a message at the tail of the next_event queue, rather than the head? Or are we only provided with the means to add events to the head of the next_event queue? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From schneider@REDACTED Mon Sep 12 14:08:14 2016 From: schneider@REDACTED (Schneider) Date: Mon, 12 Sep 2016 14:08:14 +0200 Subject: [erlang-questions] Supervisor (ab)use Message-ID: <474fbd67-9642-9ff9-b4e6-ff40accd90c5@xs4all.nl> Dear List, I want to implement a service which starts and stops a bunch of endpoints. All endpoints are very similar in their basic behavior and are started with several predefined parameters such as controlling process, a guid etc. with the endpoint id added at the end of the argument list. The simple one for one supervisor matches these requirements perfectly. Well, actually there are two types of endpoints, readers and writers. I use a simple one for one supervisor and add a child using: supervisor:start_child(Sup, [Entity_id, Type]) The supervisor is defined as:: init([NNS]) -> {ok, { {simple_one_for_one, 1, 5}, [{rtps_endpoint, {rtps_endpoint, start_link, [NNS]}, transient, 5000, worker, [rtps_endpoint]}] } }. rtps_endpoint reads: start_link(NS, Entity_id, reader) -> start_link(NS, Entity_id, rtps_reader); start_link(NS, Entity_id, writer) -> start_link(NS, Entity_id, rtps_writer); start_link(NS, Entity_id, Module) -> gen_server:start_link({via, rtps_participant, {NS, Entity_id}}, Module, [Entity_id], []). This seems to work fine, but I am wondering if there are potential issues with this construct, especially with the Modules in the child specifications and code replacement. Any advice? - Frans From jesper.louis.andersen@REDACTED Mon Sep 12 14:24:08 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 12 Sep 2016 14:24:08 +0200 Subject: [erlang-questions] Supervisor (ab)use In-Reply-To: <474fbd67-9642-9ff9-b4e6-ff40accd90c5@xs4all.nl> References: <474fbd67-9642-9ff9-b4e6-ff40accd90c5@xs4all.nl> Message-ID: On Mon, Sep 12, 2016 at 2:08 PM, Schneider wrote: > This seems to work fine, but I am wondering if there are potential issues > with this construct, especially with the Modules in the child > specifications and code replacement. >From a quick glance, your code looks right. The 'modules' section of the child specification is used by the release handler. It walks the supervisor trees and uses this section to figure out what modules is run by what processes. This then allows the system to handle release upgrades by tracking this mapping and controlling what processes needs to be upgraded. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Mon Sep 12 15:52:16 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 12 Sep 2016 15:52:16 +0200 Subject: [erlang-questions] gen_statem next_event queue question In-Reply-To: References: <9b604755-8318-168e-94b0-898933696a12@gmail.com> Message-ID: <20160912135216.GA52911@erix.ericsson.se> On Mon, Sep 12, 2016 at 04:23:10AM -0700, Kenneth Lakin wrote: > On 09/12/2016 03:07 AM, Ingela Andin wrote: > > If you send an event to yourself (gen_statem:call/cast or !) it will end up > > last in in the queue. > > Sorry, I should have been more clear in my initial message. > > It seems to me that -conceptually- gen_statem has three queues: > > * The next_event queue (which actually seems to behave like a stack) > * The "postpone" queue (which -I think- gets put at the front of the > next_event queue (but _after_ any {next_event...} actions passed along > in the state transition tuple) on state machine state change) > * The regular process mailbox > > Is this wildly incorrect? No, it is fairly correct. Apart from the normal process mailbox it has got one queue (the postponed queue) but keeps track of the current position in that queue, so that could be counted as two queues :-/ But you can only insert events at the current position (if you do not change states) or at the queue head (if you change states). There is also the special case of a timeout 0 action that inserts an event at the tail of the queue. > > If my understanding is correct, then call/cast/! will put the message at > the tail of the process mailbox, yes? Additionally, does gen_statem That is correct. It is probably not what you want. > provide the tools to put a message at the tail of the next_event queue, > rather than the head? Or are we only provided with the means to add > events to the head of the next_event queue? Adding events to the tail of the next_event queue is a missing feature, partly because there is no next_event queue. Events can now only be added to the current position in the postponed queue which could be described as the head of the next_event queue. If we would add events to the tail of the postponed queue they would be inserted before all messages in the process mailbox, but after all postponed events. This is what a timeout 0 action does. It was deemed that adding events as the immediately next to process was the most useful. And since there is only one event queue there is no defined position of after all next_event events; they can not be distinguished when they are in the queue... So if you are sure to not have any postponed events you might use the timeout 0 action as an ugly workaround. It seems you have a really tricky problem; can you rewrite to use additional states, or set a state variable to remember what to do at the last inserted event? Best Regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From sdl.web@REDACTED Mon Sep 12 16:10:06 2016 From: sdl.web@REDACTED (Leo Liu) Date: Mon, 12 Sep 2016 22:10:06 +0800 Subject: [erlang-questions] maint branch failed to build on osx Message-ID: maint branch latest commit 86d1fb0865193cce4e308baa6472885a81033f10 ./configure --with-ssl=/usr/local/opt/openssl --enable-dirty-schedulers --with-dynamic-trace=dtrace --enable-sharing-preserving make ...... make[3]: Nothing to be done for `opt'. === Leaving application dialyzer Makefile:72: warning: overriding commands for target `clean' /Users/leo/sources/erlang/otp/make/otp_subdir.mk:29: warning: ignoring old commands for target `clean' === Entering application hipe make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. make[3]: Nothing to be done for `opt'. === Leaving application hipe make[2]: *** No rule to make target `opt'. Stop. make[1]: *** [opt] Error 2 make: *** [libs] Error 2 From max.lapshin@REDACTED Mon Sep 12 19:55:42 2016 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 12 Sep 2016 20:55:42 +0300 Subject: [erlang-questions] gen_tcp:send {error, timeout} and ways to restore situation? Message-ID: Hi. As far as I know, when gen_tcp:send returns {error,timeout}, it means that it failed to send required amount of data in a requested time and now socket is in "bad" state. Not closed, but not ready for work, because we do not know how much data have been transmitted. Has anything changed? Is it possible to understand, how many data from packet have been sent to OS and try to restore situation on socket and resend the rest of packet again? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Sep 12 20:44:33 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 12 Sep 2016 20:44:33 +0200 Subject: [erlang-questions] gen_tcp:send {error, timeout} and ways to restore situation? In-Reply-To: References: Message-ID: On Mon, Sep 12, 2016 at 7:55 PM, Max Lapshin wrote: > Is it possible to understand, how many data from packet have been sent to > OS and try to restore situation on socket and resend the rest of packet > again? Isn't this impossible to know? I assume you are setting the send_timeout option, since according to the documentation, there is no way which a gen_tcp:send/2 can time out. The problem is that a TCP connection has no way of knowing where your bytes are "hiding" so to speak. The Erlang system might have buffered them and the OS never accepts receiving them. Or the OS has received the bytes, but they are in a TCP window buffer in the kernel somewhere. Or the bytes are in the outgoing TX ring-buffer of your network device. Or traveling through the internet, but getting lost somewhere. Or is sitting somewhere in the receiving hosts buffer queues, but not delivered yet. Or they have been delivered, but you don't know that this is the case. You need to write your protocol for best effort delivery in general. Otherwise you are in trouble. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Sep 12 21:37:24 2016 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 12 Sep 2016 22:37:24 +0300 Subject: [erlang-questions] gen_tcp:send {error, timeout} and ways to restore situation? In-Reply-To: References: Message-ID: I ask erlang to send 1000 bytes to network during 500 milliseconds. Erlang returns error, timeout. It may be because OS have consumed 500 bytes and 500 left inside driver. I want to ask driver to try again to transmit these 500 bytes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Mon Sep 12 23:34:32 2016 From: tony@REDACTED (Tony Rogvall) Date: Mon, 12 Sep 2016 23:34:32 +0200 Subject: [erlang-questions] gen_tcp:send {error, timeout} and ways to restore situation? In-Reply-To: References: Message-ID: <77C07FC1-95C0-4C68-9F25-10BD8A6ED17C@rogvall.se> Is that not the same as setting 1000 milliseconds timeout? ;-) Without setting the send_timeout you could also try to poll using inet:getstat(Socket, send_pend) to see if something is being sent (to the kernel.) If OTP release the subscription interface in prim_inet (or you do a hack) you could get information about empty output queue as an event. Maybe a better event in this case would to be able to get low watermark trigger so you can keep the send buffer full? A suggestion would to be able to subscribe to {subs_out_q_size_lte, Size} where the old name subs_empty_out_q could be equivalent to {subs_out_q_size_lte, 0 }. /Tony > On 12 sep 2016, at 21:37, Max Lapshin wrote: > > I ask erlang to send 1000 bytes to network during 500 milliseconds. > > Erlang returns error, timeout. It may be because OS have consumed 500 bytes and 500 left inside driver. I want to ask driver to try again to transmit these 500 bytes. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bjorn@REDACTED Tue Sep 13 05:09:36 2016 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 13 Sep 2016 05:09:36 +0200 Subject: [erlang-questions] maint branch failed to build on osx In-Reply-To: References: Message-ID: On Mon, Sep 12, 2016 at 4:10 PM, Leo Liu wrote: > maint branch latest commit 86d1fb0865193cce4e308baa6472885a81033f10 > > ./configure --with-ssl=/usr/local/opt/openssl --enable-dirty-schedulers --with-dynamic-trace=dtrace --enable-sharing-preserving > make > Did you run "git clean" to clean the repository before running those commands? Cleaning the repository is often necessary if you have switched from the master branch to the maint branch or vice versa. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From sdl.web@REDACTED Tue Sep 13 10:47:53 2016 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 13 Sep 2016 16:47:53 +0800 Subject: [erlang-questions] maint branch failed to build on osx In-Reply-To: (=?iso-8859-1?Q?=22Bj=F6rn?= Gustavsson"'s message of "Tue, 13 Sep 2016 05:09:36 +0200") References: Message-ID: On 2016-09-13 05:09 +0200, Bj?rn Gustavsson wrote: > On Mon, Sep 12, 2016 at 4:10 PM, Leo Liu wrote: [snipped 6 lines] > Did you run "git clean" to clean the repository before running those commands? > > Cleaning the repository is often necessary if you have switched from > the master branch to the maint branch or vice versa. > > /Bjorn Did that and got the same failure. Then make clean and got the same failure. Looks like somewhere something is wrong. Leo From dmytro.lytovchenko@REDACTED Tue Sep 13 11:13:59 2016 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Tue, 13 Sep 2016 09:13:59 +0000 Subject: [erlang-questions] maint branch failed to build on osx In-Reply-To: References: Message-ID: Assuming it built before but doesn't build now: make clean does not do complete cleaning, some stuff remains on disk and can create problems. I can blame the overcomplicated build system. Anyway try git clean -f -x, or do a clean checkout from git (or faster: git clone from one directory to another, but then you lose git remotes). If it never built for you before, then no amount of cleaning is going to fix it. Show the errors which you receive. tis 13 sep. 2016 kl 10:48 skrev Leo Liu : > > > On 2016-09-13 05:09 +0200, Bj?rn Gustavsson wrote: > > On Mon, Sep 12, 2016 at 4:10 PM, Leo Liu wrote: > [snipped 6 lines] > > Did you run "git clean" to clean the repository before running those > commands? > > > > Cleaning the repository is often necessary if you have switched from > > the master branch to the maint branch or vice versa. > > > > /Bjorn > > Did that and got the same failure. Then make clean and got the same > failure. > > Looks like somewhere something is wrong. > > Leo > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silviu.cpp@REDACTED Tue Sep 13 11:50:08 2016 From: silviu.cpp@REDACTED (Caragea Silviu) Date: Tue, 13 Sep 2016 12:50:08 +0300 Subject: [erlang-questions] debug erlang core dumps with gdb Message-ID: Hello, I'm using the last erlang package from Erlang Solution (19.0 - seems 19.0.3 is available only if you are using esl-erlang) and I want to debug a generated core dump with GDB. The issue I facing is that the beam.smp seems is not including debugging symbols. I inspired myself from: https://www.erlang-solutions.com/blog/how-to-analyse-a-beam-core-dump.html I changed a nif library I have to generate a crash. when I run : gdb my_project/rel/myapp/erts-8.0/bin/beam.smp core.2_scheduler.14306.silviu-desktop.1473754498 -d /home/silviu/Desktop/otp_src_19.0/erts/emulator I get this warning first: Reading symbols from my_project/rel/myapp/erts-8.0/bin/beam.smp ...(no debugging symbols found)...done. Then when I type backtrace: #0 memset () at ../sysdeps/x86_64/memset.S:78 #1 0x00007ffa712a75cc in fill_window () from /home/silviu/Desktop/my_project/rel/myapp/lib/ezlib-1.0/priv/ezlib_nif.so #2 0x00007ffa712a7f20 in deflate_slow () from /home/silviu/Desktop/my_project/rel/myapp/lib/ezlib-1.0/priv/ezlib_nif.so #3 0x00007ffa712a8fd0 in deflate () from /home/silviu/Desktop/my_project/rel/myapp/lib/ezlib-1.0/priv/ezlib_nif.so #4 0x00007ffa712a6527 in process_buffer (session=0x7ffa71700968, data=, len=) at c_src/ezlib.cc:103 #5 0x00007ffa712a6abb in nif_zlib_process_buffer (env=0x7ffaaa13de00, argc=, argv=0x7ffab03c4180) at c_src/ezlib.cc:289 #6 0x000000000044426f in process_main () #7 0x00000000004ce1bd in ?? () #8 0x00000000005f2fcb in ?? () #9 0x00007ffaf10a2184 in start_thread (arg=0x7ffaaa13e700) at pthread_create.c:312 #10 0x00007ffaf0bc737d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 I can see the stack correctly in the ezlib nif I have but not the erlang VM which called the nif which shows as ?? because of the leak of symbols. There is any way to fix this ? Also I have a second problem when I try to run in gdb: source /home/silviu/Desktop/otp_src_19.0/erts/etc/unix/etp-commands.in I get: %--------------------------------------------------------------------------- % Use etp-help for a command overview and general help. % % To use the Erlang support module, the environment variable ROOTDIR % must be set to the toplevel installation directory of Erlang/OTP, % so the etp-commands file becomes: % $ROOTDIR/erts/etc/unix/etp-commands % Also, erl and erlc must be in the path. %--------------------------------------------------------------------------- etp-set-max-depth 20 etp-set-max-string-length 100 --------------- System Information --------------- OTP release: /home/silviu/Desktop/otp_src_19.0/erts/etc/unix/ etp-commands.in:3812: Error in sourced command file: Cannot access memory at address 0x38003931 Any idea what can be wrong ? Silviu -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Sep 13 12:01:57 2016 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 13 Sep 2016 12:01:57 +0200 Subject: [erlang-questions] maint branch failed to build on osx In-Reply-To: References: Message-ID: On Tue, Sep 13, 2016 at 10:47 AM, Leo Liu wrote: > > > On 2016-09-13 05:09 +0200, Bj?rn Gustavsson wrote: >> On Mon, Sep 12, 2016 at 4:10 PM, Leo Liu wrote: > [snipped 6 lines] >> Did you run "git clean" to clean the repository before running those commands? >> >> Cleaning the repository is often necessary if you have switched from >> the master branch to the maint branch or vice versa. >> >> /Bjorn > > Did that and got the same failure. Then make clean and got the same > failure. > > Looks like somewhere something is wrong. > I can't reproduce your problem. I used the same command line (except for the location of the ssl library) as you. Use "git clean -dxf" or build in a newly cloned repository as suggested by Dmytro Lytovchenko. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From essen@REDACTED Tue Sep 13 12:05:59 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 13 Sep 2016 12:05:59 +0200 Subject: [erlang-questions] maint branch failed to build on osx In-Reply-To: References: Message-ID: <71eedf9d-5f14-c16b-0dff-b1814b06c4ca@ninenines.eu> Blaming the build system is not helpful, all it's missing is a target that puts the repository back to its initial state. I suspect that target was never added because it's just as simple to do a git clean in most cases. Perhaps the only overcomplicated thing to fix is properly documenting this. On 09/13/2016 11:13 AM, Dmytro Lytovchenko wrote: > Assuming it built before but doesn't build now: > make clean does not do complete cleaning, some stuff remains on disk and > can create problems. I can blame the overcomplicated build system. > Anyway try git clean -f -x, or do a clean checkout from git (or faster: > git clone from one directory to another, but then you lose git remotes). > > If it never built for you before, then no amount of cleaning is going to > fix it. Show the errors which you receive. > > tis 13 sep. 2016 kl 10:48 skrev Leo Liu >: > > > > On 2016-09-13 05:09 +0200, Bj?rn Gustavsson wrote: > > On Mon, Sep 12, 2016 at 4:10 PM, Leo Liu > wrote: > [snipped 6 lines] > > Did you run "git clean" to clean the repository before running > those commands? > > > > Cleaning the repository is often necessary if you have switched from > > the master branch to the maint branch or vice versa. > > > > /Bjorn > > Did that and got the same failure. Then make clean and got the same > failure. > > Looks like somewhere something is wrong. > > Leo > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From dmytro.lytovchenko@REDACTED Tue Sep 13 12:30:09 2016 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Tue, 13 Sep 2016 10:30:09 +0000 Subject: [erlang-questions] maint branch failed to build on osx In-Reply-To: <71eedf9d-5f14-c16b-0dff-b1814b06c4ca@ninenines.eu> References: <71eedf9d-5f14-c16b-0dff-b1814b06c4ca@ninenines.eu> Message-ID: Well, sometimes it happens that even git clean -fx doesn't return sources to the initial state. So there is something tricky happening under git-ignored paths, so I believe. Also the build output is spread in multiple tmp directories + source directories, some of them are under gitignore and some other are not. There are flaws in this scheme of things, and i've made my attempts to fix the problem with CMake project. Though it is in early stage and is only able to build emulator and helper binaries. tis 13 sep. 2016 kl 12:06 skrev Lo?c Hoguin : > Blaming the build system is not helpful, all it's missing is a target > that puts the repository back to its initial state. I suspect that > target was never added because it's just as simple to do a git clean in > most cases. > > Perhaps the only overcomplicated thing to fix is properly documenting this. > > On 09/13/2016 11:13 AM, Dmytro Lytovchenko wrote: > > Assuming it built before but doesn't build now: > > make clean does not do complete cleaning, some stuff remains on disk and > > can create problems. I can blame the overcomplicated build system. > > Anyway try git clean -f -x, or do a clean checkout from git (or faster: > > git clone from one directory to another, but then you lose git remotes). > > > > If it never built for you before, then no amount of cleaning is going to > > fix it. Show the errors which you receive. > > > > tis 13 sep. 2016 kl 10:48 skrev Leo Liu > >: > > > > > > > > On 2016-09-13 05:09 +0200, Bj?rn Gustavsson wrote: > > > On Mon, Sep 12, 2016 at 4:10 PM, Leo Liu > > wrote: > > [snipped 6 lines] > > > Did you run "git clean" to clean the repository before running > > those commands? > > > > > > Cleaning the repository is often necessary if you have switched > from > > > the master branch to the maint branch or vice versa. > > > > > > /Bjorn > > > > Did that and got the same failure. Then make clean and got the same > > failure. > > > > Looks like somewhere something is wrong. > > > > Leo > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Tue Sep 13 14:29:38 2016 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 13 Sep 2016 20:29:38 +0800 Subject: [erlang-questions] maint branch failed to build on osx References: <71eedf9d-5f14-c16b-0dff-b1814b06c4ca@ninenines.eu> Message-ID: On 2016-09-13 10:30 +0000, Dmytro Lytovchenko wrote: > Well, sometimes it happens that even git clean -fx doesn't return sources > to the initial state. So there is something tricky happening under > git-ignored paths, so I believe. Also the build output is spread in > multiple tmp directories + source directories, some of them are under > gitignore and some other are not. > > There are flaws in this scheme of things, and i've made my attempts to fix > the problem with CMake project. Though it is in early stage and is only > able to build emulator and helper binaries. The error message doesn't tell much about what is wrong besides: make[2]: *** No rule to make target `opt'. Stop. On 2016-09-13 12:01 +0200, Bj?rn Gustavsson wrote: > I can't reproduce your problem. I used the same command line (except > for the location of the ssl library) as you. > > Use "git clean -dxf" or build in a newly cloned repository as > suggested by Dmytro Lytovchenko. > > /Bjorn I did "git clean -dxf" and rebuilt and succeeded. Thanks to all for the help. Leo From silviu.cpp@REDACTED Tue Sep 13 16:04:34 2016 From: silviu.cpp@REDACTED (Caragea Silviu) Date: Tue, 13 Sep 2016 17:04:34 +0300 Subject: [erlang-questions] debug erlang core dumps with gdb In-Reply-To: References: Message-ID: After I compiled erlang from sources I don't have any longer this issues. I compiled with systemtap support. Silviu On Tue, Sep 13, 2016 at 12:50 PM, Caragea Silviu wrote: > Hello, > > I'm using the last erlang package from Erlang Solution (19.0 - seems > 19.0.3 is available only if you are using esl-erlang) and I want to debug a > generated core dump with GDB. > > The issue I facing is that the beam.smp seems is not including debugging > symbols. > > I inspired myself from: https://www.erlang-solutions. > com/blog/how-to-analyse-a-beam-core-dump.html > > I changed a nif library I have to generate a crash. > > when I run : > > gdb my_project/rel/myapp/erts-8.0/bin/beam.smp > core.2_scheduler.14306.silviu-desktop.1473754498 -d > /home/silviu/Desktop/otp_src_19.0/erts/emulator > > I get this warning first: > > Reading symbols from my_project/rel/myapp/erts-8.0/bin/beam.smp ...(no > debugging symbols found)...done. > > Then when I type backtrace: > > #0 memset () at ../sysdeps/x86_64/memset.S:78 > #1 0x00007ffa712a75cc in fill_window () from /home/silviu/Desktop/my_ > project/rel/myapp/lib/ezlib-1.0/priv/ezlib_nif.so > #2 0x00007ffa712a7f20 in deflate_slow () from /home/silviu/Desktop/my_ > project/rel/myapp/lib/ezlib-1.0/priv/ezlib_nif.so > #3 0x00007ffa712a8fd0 in deflate () from /home/silviu/Desktop/my_ > project/rel/myapp/lib/ezlib-1.0/priv/ezlib_nif.so > #4 0x00007ffa712a6527 in process_buffer (session=0x7ffa71700968, > data=, len=) at c_src/ezlib.cc:103 > #5 0x00007ffa712a6abb in nif_zlib_process_buffer (env=0x7ffaaa13de00, > argc=, argv=0x7ffab03c4180) at c_src/ezlib.cc:289 > #6 0x000000000044426f in process_main () > #7 0x00000000004ce1bd in ?? () > #8 0x00000000005f2fcb in ?? () > #9 0x00007ffaf10a2184 in start_thread (arg=0x7ffaaa13e700) at > pthread_create.c:312 > #10 0x00007ffaf0bc737d in clone () at ../sysdeps/unix/sysv/linux/ > x86_64/clone.S:111 > > I can see the stack correctly in the ezlib nif I have but not the erlang > VM which called the nif which shows as ?? because of the leak of symbols. > > There is any way to fix this ? > > Also I have a second problem when I try to run in gdb: > > source /home/silviu/Desktop/otp_src_19.0/erts/etc/unix/etp-commands.in > > I get: > > %----------------------------------------------------------- > ---------------- > % Use etp-help for a command overview and general help. > % > % To use the Erlang support module, the environment variable ROOTDIR > % must be set to the toplevel installation directory of Erlang/OTP, > % so the etp-commands file becomes: > % $ROOTDIR/erts/etc/unix/etp-commands > % Also, erl and erlc must be in the path. > %----------------------------------------------------------- > ---------------- > etp-set-max-depth 20 > etp-set-max-string-length 100 > --------------- System Information --------------- > OTP release: /home/silviu/Desktop/otp_src_19.0/erts/etc/unix/etp- > commands.in:3812: Error in sourced command file: > Cannot access memory at address 0x38003931 > > Any idea what can be wrong ? > > Silviu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Korpilla@REDACTED Tue Sep 13 17:16:48 2016 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Tue, 13 Sep 2016 17:16:48 +0200 Subject: [erlang-questions] Compiling Erlang without RC4? Message-ID: Hello. We currently have to work with a system where somebody thought removing rc4.h would solve the security issues involved with this weak algorithm... Is there any way to build Erlang without RC4 (but still with crypto functionality)? Thanks and best regards, Oliver From ahf@REDACTED Tue Sep 13 20:16:05 2016 From: ahf@REDACTED (=?UTF-8?B?QWxleGFuZGVyIEbDpnLDuHk=?=) Date: Tue, 13 Sep 2016 20:16:05 +0200 Subject: [erlang-questions] [ANN] Sphincs - Post-quantum Signature Scheme Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Sphincs 1.0.0 is out. Sphincs is an Erlang NIF for the SPHINCS-256 post-quantum signature scheme made by D. J. Bernstein, D. Hopwood, A. H?lsing, T. Lange, R. Niederhagen, L. Papachristodoulou, M. Schneider, P. Schwabe, and Z. Wilcox-O'Hearn. Sphincs is designed to provide 2^128 bits of security in a world where an adversary have access to a quantum computer. Sphincs can be used as a drop-in replacement for enacl's Ed25519 signature scheme if you are interested in experimenting with making your cryptographic protocols post-quantum secure. Note that public keys and secret keys are around 1 KB in size each and signatures are around 41 KB in size. This is a lot larger than what you will get with Ed25519 -- and sphincs is also a lot slower :-) The Sphincs Erlang NIF is available from: Primary: https://lab.baconsvin.org/ahf/sphincs Mirror: https://github.com/ahf/sphincs You can read more about the SPHINCS-256 signature scheme at http://sphincs.cr.yp.to Happy hacking. Cheers, Alex. -----BEGIN PGP SIGNATURE----- iQIbBAEBCgAGBQJX2EF1AAoJEPm8L+IrCM6PrDYP9jkTbdTGWvF+NBy//3AC+uyq SPOdFylMj7zSyza+n+TcpCPs0uOb6xePTL2wI2Yq1v986r2aCZkwTEuqJTp7BbGA xDmrRclrLKzxEZfpzlPPeORcwSUmeyT7SdhYDux0RldA9E8VqcC/YpFJ2PzgGTk6 cUD2ROMDSGeX47pGmMW2zMdQcONSw9B6WzJejUwcmPX+EyOUr36Zuh/7R6melBXS XyCl8EFBURH2wmwYu+tNhaztH0vGCkcrGjWs50zs8bWCJO254Icm7Hg0gyDyMRrc 06NUj0Uon5BIw+HBqCkfuPqVMrRbAs5exFKQnE8biv3kZMEUWbMPb2EmGji8bRBR sTv6oMS/l9h0eNNs9KmIBO2Byln7p9wboyg6bBRGesFpn6en8MPEFelXAlNSTU1F MoQdjcXFNNIMjm/cYiCZjU7tNdXdCvCxw4lvHTQrEMTXbsmo+FUeHZGXnoXBWhkB nYRLYbQc0qYM1+DC5wFGe2aYYAb/vcshM98ympOGfSHjtazL+AykpukUkBxyurfv IEJ65EVmRgfue49QlxteZiKK44R8VGRjbE+KVdIBdL0I+HSyAymqp4Rvr7CCgnTd 3kAaKg4GM0QQ7e/gMCDtf4moD8rWTeTO10CQqlesg56xnyBaEam00unYTNA4uw0A auEVNZgMzmKf+M9bNC8= =hpsC -----END PGP SIGNATURE----- -- Alexander F?r?y From ahf@REDACTED Tue Sep 13 20:42:33 2016 From: ahf@REDACTED (=?UTF-8?B?QWxleGFuZGVyIEbDpnLDuHk=?=) Date: Tue, 13 Sep 2016 20:42:33 +0200 Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: References: Message-ID: On 13 September 2016 at 17:16, Oliver Korpilla wrote: > We currently have to work with a system where somebody thought removing rc4.h would solve the security issues involved with this weak algorithm... > > Is there any way to build Erlang without RC4 (but still with crypto functionality)? It doesn't look like the RC4 functionality is hidden behind a guard in the C source code, but I don't think you should be overly worried about using an Erlang release that contains RC4 support. If you take a look at the ciphers that the SSL application will use by default, you will see that there's no RC4 ciphers included (at least not in my OTP-18 installation locally): lists:foreach(fun (Suite) -> io:format("~p~n", [Suite]) end, ssl:cipher_suites()). You could consider filtering out the 3DES ciphers that are enabled by default though[1] using the {ciphers, [...]} option for SSL connections. Cheers, Alex. [1]: https://sweet32.info -- Alexander F?r?y From Oliver.Korpilla@REDACTED Tue Sep 13 23:03:03 2016 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Tue, 13 Sep 2016 23:03:03 +0200 Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: References: , Message-ID: Hello, Alexander. You misunderstand... I'm not concerned at all. The Linux distribution I have to work with removed the rc4.h header and without it I can not compile the Erlang runtime environment (and not deploy my application). I did a cursory look but it is as you say - I found no guards and there were plenty of references towards definitions from that header, so I was a bit out on a limb to ask if anything knew a trick to compile the Erlang runtime without this header... Thanks, Oliver ? ? Gesendet:?Dienstag, 13. September 2016 um 20:42 Uhr Von:?"Alexander F?r?y" An:?erlang-questions Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? On 13 September 2016 at 17:16, Oliver Korpilla wrote: > We currently have to work with a system where somebody thought removing rc4.h would solve the security issues involved with this weak algorithm... > > Is there any way to build Erlang without RC4 (but still with crypto functionality)? It doesn't look like the RC4 functionality is hidden behind a guard in the C source code, but I don't think you should be overly worried about using an Erlang release that contains RC4 support. If you take a look at the ciphers that the SSL application will use by default, you will see that there's no RC4 ciphers included (at least not in my OTP-18 installation locally): lists:foreach(fun (Suite) -> io:format("~p~n", [Suite]) end, ssl:cipher_suites()). You could consider filtering out the 3DES ciphers that are enabled by default though[1] using the {ciphers, [...]} option for SSL connections. Cheers, Alex. [1]: https://sweet32.info -- Alexander F?r?y _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] From charles.shuller@REDACTED Tue Sep 13 23:06:26 2016 From: charles.shuller@REDACTED (Charles Shuller) Date: Tue, 13 Sep 2016 16:06:26 -0500 Subject: [erlang-questions] MyModule:start_link/? vs supervisor:start_link/3 Message-ID: Hello, I've developed a marked preference for starting the primary supervisor in my application callback modules as: supervisor:start_link({local, my_module}, my_module, InitArgs) But I've noticed that most code I see seems to prefer: my_module:start_link(InitArgs) where my_module:start_link always calls supervisor:start_link call. Is there any advantage to specifying a custom start_link in the supervisor callback module?? It seems to me that the "owner" of the supervisor is the application, and therefore the configuration (i.e. parameter values) should be performed by the application callback, and not the supervisor callback. Thanks! Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.rascao@REDACTED Wed Sep 14 00:34:47 2016 From: luis.rascao@REDACTED (=?UTF-8?B?THVpcyBSYXNjw6Nv?=) Date: Tue, 13 Sep 2016 23:34:47 +0100 Subject: [erlang-questions] relup with rebar3 In-Reply-To: References: Message-ID: Have you tried it in not dev mode? On Thu, Sep 8, 2016 at 5:58 PM, Anatoly Yakovenko wrote: > anyone familiar with this error: > $ ./rebar3 relup > > ===> Verifying dependencies... > ===> Compiling minuteman > ===> Starting relx build process ... > ===> Resolving OTP Applications from directories: > /home/ayakovenko/Public/minuteman/_build/default/lib > /home/ayakovenko/erlangs/lib > ===> Resolved minuteman-0.0.2 > ===> Dev mode enabled, release will be symlinked > ===> Including Erts from /home/ayakovenko/erlangs > ===> release successfully created! > ===> Starting relx build process ... > ===> Resolving OTP Applications from directories: > /home/ayakovenko/Public/minuteman/_build/default/lib > /home/ayakovenko/erlangs/lib > /home/ayakovenko/Public/minuteman/_build/default/rel > ===> Resolving available OTP Releases from directories: > /home/ayakovenko/Public/minuteman/_build/default/lib > /home/ayakovenko/Public/minuteman/_build/default/rel > ===> could not find app kernel {2,14,4} > > Thanks, > Anatoly > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeyakovenko@REDACTED Wed Sep 14 00:58:47 2016 From: aeyakovenko@REDACTED (Anatoly Yakovenko) Date: Tue, 13 Sep 2016 22:58:47 +0000 Subject: [erlang-questions] relup with rebar3 In-Reply-To: References: Message-ID: What do you mean? how do i switch to `dev` mode? On Tue, Sep 13, 2016 at 3:35 PM Luis Rasc?o wrote: > Have you tried it in not dev mode? > > On Thu, Sep 8, 2016 at 5:58 PM, Anatoly Yakovenko > wrote: > >> anyone familiar with this error: >> $ ./rebar3 relup >> >> ===> Verifying dependencies... >> ===> Compiling minuteman >> ===> Starting relx build process ... >> ===> Resolving OTP Applications from directories: >> /home/ayakovenko/Public/minuteman/_build/default/lib >> /home/ayakovenko/erlangs/lib >> ===> Resolved minuteman-0.0.2 >> ===> Dev mode enabled, release will be symlinked >> ===> Including Erts from /home/ayakovenko/erlangs >> ===> release successfully created! >> ===> Starting relx build process ... >> ===> Resolving OTP Applications from directories: >> /home/ayakovenko/Public/minuteman/_build/default/lib >> /home/ayakovenko/erlangs/lib >> /home/ayakovenko/Public/minuteman/_build/default/rel >> ===> Resolving available OTP Releases from directories: >> /home/ayakovenko/Public/minuteman/_build/default/lib >> /home/ayakovenko/Public/minuteman/_build/default/rel >> ===> could not find app kernel {2,14,4} >> >> Thanks, >> Anatoly >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik.x.nord@REDACTED Wed Sep 14 09:57:22 2016 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Wed, 14 Sep 2016 09:57:22 +0200 Subject: [erlang-questions] Patch package OTP 19.0.6 released Message-ID: <1e43f08a-dd20-ce7e-9f46-92d9f7999797@ericsson.com> Patch Package: OTP 19.0.6 Git Tag: OTP-19.0.6 Date: 2016-09-14 Trouble Report Id: OTP-13889 Seq num: System: OTP Release: 19 Application: erts-8.0.4 Predecessor: OTP 19.0.5 Check out the git tag OTP-19.0.6, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- erts-8.0.4 ------------------------------------------------------ --------------------------------------------------------------------- The erts-8.0.4 application can be applied independently of other applications on a full OTP 19 installation. --- Fixed Bugs and Malfunctions --- OTP-13889 Application(s): erts Fixed a VM crash that occured in garbage collection of a process when it had received maps over the distribution. This bug was introduced in ERTS version 8.0 (OTP 19.0). Full runtime dependencies of erts-8.0.4: kernel-5.0, sasl-3.0, stdlib-3.0 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From aschultz@REDACTED Wed Sep 14 10:08:59 2016 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 14 Sep 2016 10:08:59 +0200 (CEST) Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: References: Message-ID: <1443597593.75945.1473840539093.JavaMail.zimbra@tpip.net> Hi Oliver, You could try the attached patch. This just disables the rc4 support, for a pull request, some adjustments to the test suite might be required as well. I don't have a OpenSSL without RC4, so this is purely guesswork! Andreas ----- Original Message ----- > From: "Oliver Korpilla" > To: "Alexander F?r?y" > Cc: "erlang-questions" > Sent: Tuesday, September 13, 2016 11:03:03 PM > Subject: Re: [erlang-questions] Compiling Erlang without RC4? > Hello, Alexander. > > You misunderstand... I'm not concerned at all. The Linux distribution I have to > work with removed the rc4.h header and without it I can not compile the Erlang > runtime environment (and not deploy my application). > > I did a cursory look but it is as you say - I found no guards and there were > plenty of references towards definitions from that header, so I was a bit out > on a limb to ask if anything knew a trick to compile the Erlang runtime without > this header... > > Thanks, > Oliver >? >? > > Gesendet:?Dienstag, 13. September 2016 um 20:42 Uhr > Von:?"Alexander F?r?y" > An:?erlang-questions > Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? > On 13 September 2016 at 17:16, Oliver Korpilla wrote: >> We currently have to work with a system where somebody thought removing rc4.h >> would solve the security issues involved with this weak algorithm... >> >> Is there any way to build Erlang without RC4 (but still with crypto >> functionality)? > > It doesn't look like the RC4 functionality is hidden behind a guard in > the C source code, but I don't think you should be overly worried > about using an Erlang release that contains RC4 support. > > If you take a look at the ciphers that the SSL application will use by > default, you will see that there's no RC4 ciphers included (at least > not in my OTP-18 installation locally): > > lists:foreach(fun (Suite) -> io:format("~p~n", [Suite]) end, > ssl:cipher_suites()). > > You could consider filtering out the 3DES ciphers that are enabled by > default though[1] using the {ciphers, [...]} option for SSL > connections. > > Cheers, > Alex. > > [1]: https://sweet32.info > > > -- > Alexander F?r?y > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-suport-for-building-without-RC4-support-in-OpenS.patch Type: text/x-patch Size: 2950 bytes Desc: not available URL: From luis.rascao@REDACTED Wed Sep 14 10:15:37 2016 From: luis.rascao@REDACTED (=?UTF-8?B?THVpcyBSYXNjw6Nv?=) Date: Wed, 14 Sep 2016 09:15:37 +0100 Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: <1443597593.75945.1473840539093.JavaMail.zimbra@tpip.net> References: <1443597593.75945.1473840539093.JavaMail.zimbra@tpip.net> Message-ID: You could build OpenSSL yourself and link statically link Erlang with it, would that work also maybe? On Wed, Sep 14, 2016 at 9:08 AM, Andreas Schultz wrote: > Hi Oliver, > > You could try the attached patch. This just disables the rc4 support, > for a pull request, some adjustments to the test suite might be > required as well. > > I don't have a OpenSSL without RC4, so this is purely guesswork! > > Andreas > > ----- Original Message ----- > > From: "Oliver Korpilla" > > To: "Alexander F?r?y" > > Cc: "erlang-questions" > > Sent: Tuesday, September 13, 2016 11:03:03 PM > > Subject: Re: [erlang-questions] Compiling Erlang without RC4? > > > Hello, Alexander. > > > > You misunderstand... I'm not concerned at all. The Linux distribution I > have to > > work with removed the rc4.h header and without it I can not compile the > Erlang > > runtime environment (and not deploy my application). > > > > I did a cursory look but it is as you say - I found no guards and there > were > > plenty of references towards definitions from that header, so I was a > bit out > > on a limb to ask if anything knew a trick to compile the Erlang runtime > without > > this header... > > > > Thanks, > > Oliver > > > > > > > > Gesendet: Dienstag, 13. September 2016 um 20:42 Uhr > > Von: "Alexander F?r?y" > > An: erlang-questions > > Betreff: Re: [erlang-questions] Compiling Erlang without RC4? > > On 13 September 2016 at 17:16, Oliver Korpilla > wrote: > >> We currently have to work with a system where somebody thought removing > rc4.h > >> would solve the security issues involved with this weak algorithm... > >> > >> Is there any way to build Erlang without RC4 (but still with crypto > >> functionality)? > > > > It doesn't look like the RC4 functionality is hidden behind a guard in > > the C source code, but I don't think you should be overly worried > > about using an Erlang release that contains RC4 support. > > > > If you take a look at the ciphers that the SSL application will use by > > default, you will see that there's no RC4 ciphers included (at least > > not in my OTP-18 installation locally): > > > > lists:foreach(fun (Suite) -> io:format("~p~n", [Suite]) end, > > ssl:cipher_suites()). > > > > You could consider filtering out the 3DES ciphers that are enabled by > > default though[1] using the {ciphers, [...]} option for SSL > > connections. > > > > Cheers, > > Alex. > > > > [1]: https://sweet32.info > > > > > > -- > > Alexander F?r?y > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions[ > 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 > > -- PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260 -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.rascao@REDACTED Wed Sep 14 10:17:02 2016 From: luis.rascao@REDACTED (=?UTF-8?B?THVpcyBSYXNjw6Nv?=) Date: Wed, 14 Sep 2016 09:17:02 +0100 Subject: [erlang-questions] relup with rebar3 In-Reply-To: References: Message-ID: Your rebar3 log says: "Dev mode enabled, release will be symlinked" So probably somewhere in your rebar.config you have the dev_mode option set, my suggestion is to try out the relup while *not* in dev mode On Tue, Sep 13, 2016 at 11:58 PM, Anatoly Yakovenko wrote: > What do you mean? how do i switch to `dev` mode? > > On Tue, Sep 13, 2016 at 3:35 PM Luis Rasc?o wrote: > >> Have you tried it in not dev mode? >> >> On Thu, Sep 8, 2016 at 5:58 PM, Anatoly Yakovenko >> wrote: >> >>> anyone familiar with this error: >>> $ ./rebar3 relup >>> >>> ===> Verifying dependencies... >>> ===> Compiling minuteman >>> ===> Starting relx build process ... >>> ===> Resolving OTP Applications from directories: >>> /home/ayakovenko/Public/minuteman/_build/default/lib >>> /home/ayakovenko/erlangs/lib >>> ===> Resolved minuteman-0.0.2 >>> ===> Dev mode enabled, release will be symlinked >>> ===> Including Erts from /home/ayakovenko/erlangs >>> ===> release successfully created! >>> ===> Starting relx build process ... >>> ===> Resolving OTP Applications from directories: >>> /home/ayakovenko/Public/minuteman/_build/default/lib >>> /home/ayakovenko/erlangs/lib >>> /home/ayakovenko/Public/minuteman/_build/default/rel >>> ===> Resolving available OTP Releases from directories: >>> /home/ayakovenko/Public/minuteman/_build/default/lib >>> /home/ayakovenko/Public/minuteman/_build/default/rel >>> ===> could not find app kernel {2,14,4} >>> >>> Thanks, >>> Anatoly >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260 >> > -- PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Wed Sep 14 10:42:45 2016 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Wed, 14 Sep 2016 11:42:45 +0300 Subject: [erlang-questions] Stopping a process with its supervision subtree Message-ID: Hello, In my application I have a processes (lets say P_X), that are started by starting a dedicated supervisor (S_X), which starts the process P_X and several related processes as its children. The S_X supervisors are started under the one_for_one supervisor (say MainSup). The supervision tree schematically looks as the following for two P_X started, when X = 1..2. MainSup * S_1 * P_1 * Other_1 * S_2 * P_2 * Other_2 I need to stop the entire supervisor S_X when the process P_X is done with its job. Is it OK to call supervisor:stop_child(MainSup, X) from P_X process? I experimented with that and it works. Just I'm now not sure, if this is a correct way for doing that. The following is an excerpt from the P_X: handle_info(deadline, State = #state{x = X}) -> ok = supervisor:terminate_child(MainSup, X), io:format("Stopped ~p~n", [X]), {stop, normal, State}; The last two lines are not executed, as the supervisor:terminate_child is synchronous and returns only after the P_X is terminated. Another option, as I understand, would be to start a process above the MainSup and monitor all P_X processes and then stop the corresponding supervisors S_X when the DOWN messages are received. Although I would like to avoid creating such processes as well as to implement own supervisor. Karolis From magnus@REDACTED Wed Sep 14 11:37:54 2016 From: magnus@REDACTED (Magnus Henoch) Date: Wed, 14 Sep 2016 10:37:54 +0100 Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: References: Message-ID: There was a recent change in the maint branch handling the same situation for DES, so the fix for RC4 would probably be similar: https://github.com/erlang/otp/compare/e8057333%5E%5E...e8057333 Regards, Magnus On Tue, Sep 13, 2016 at 4:16 PM, Oliver Korpilla wrote: > Hello. > > We currently have to work with a system where somebody thought removing > rc4.h would solve the security issues involved with this weak algorithm... > > Is there any way to build Erlang without RC4 (but still with crypto > functionality)? > > Thanks and best regards, > Oliver > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Korpilla@REDACTED Wed Sep 14 12:39:40 2016 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Wed, 14 Sep 2016 12:39:40 +0200 Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: References: <1443597593.75945.1473840539093.JavaMail.zimbra@tpip.net>, Message-ID: Hello, Luis. Yes, I thought about building Erlang on a more "full-featured" machine and deploying it as a statically linked binary as alternate solution. Since we rely on SCTP support in the kernel, however, my personal guess would be that this is a little risky but doable and will require testing if all features still work properly on target. So, yes, this would have been our next option to pursue. :) Thanks, Oliver ? Gesendet:?Mittwoch, 14. September 2016 um 10:15 Uhr Von:?"Luis Rasc?o" An:?"Andreas Schultz" Cc:?"Oliver Korpilla" , erlang-questions Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? You could build OpenSSL yourself and link statically link Erlang with it, would that work also maybe? ? On Wed, Sep 14, 2016 at 9:08 AM, Andreas Schultz wrote:Hi Oliver, You could try the attached patch. This just disables the rc4 support, for a pull request, some adjustments to the test suite might be required as well. I don't have a OpenSSL without RC4, so this is purely guesswork! Andreas ----- Original Message ----- > From: "Oliver Korpilla" > To: "Alexander F?r?y" > Cc: "erlang-questions" > Sent: Tuesday, September 13, 2016 11:03:03 PM > Subject: Re: [erlang-questions] Compiling Erlang without RC4? > Hello, Alexander. > > You misunderstand... I'm not concerned at all. The Linux distribution I have to > work with removed the rc4.h header and without it I can not compile the Erlang > runtime environment (and not deploy my application). > > I did a cursory look but it is as you say - I found no guards and there were > plenty of references towards definitions from that header, so I was a bit out > on a limb to ask if anything knew a trick to compile the Erlang runtime without > this header... > > Thanks, > Oliver >? >? > > Gesendet:?Dienstag, 13. September 2016 um 20:42 Uhr > Von:?"Alexander F?r?y" > An:?erlang-questions > Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? > On 13 September 2016 at 17:16, Oliver Korpilla wrote: >> We currently have to work with a system where somebody thought removing rc4.h >> would solve the security issues involved with this weak algorithm... >> >> Is there any way to build Erlang without RC4 (but still with crypto >> functionality)? > > It doesn't look like the RC4 functionality is hidden behind a guard in > the C source code, but I don't think you should be overly worried > about using an Erlang release that contains RC4 support. > > If you take a look at the ciphers that the SSL application will use by > default, you will see that there's no RC4 ciphers included (at least > not in my OTP-18 installation locally): > > lists:foreach(fun (Suite) -> io:format("~p~n", [Suite]) end, > ssl:cipher_suites()). > > You could consider filtering out the 3DES ciphers that are enabled by > default though[1] using the {ciphers, [...]} option for SSL > connections. > > Cheers, > Alex. > > [1]: https://sweet32.info[https://sweet32.info] > > > -- > Alexander F?r?y > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED[erlang-questions@REDACTED] > http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions][http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]] > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED[erlang-questions@REDACTED] > http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED[erlang-questions@REDACTED] http://erlang.org/mailman/listinfo/erlang-questions ?? ?-- PGP fingerprint:?F708 E141 AE8D 2D38 E1BC ?DF3D 1719 3EA0 647D 7260 From sperber@REDACTED Wed Sep 14 09:47:51 2016 From: sperber@REDACTED (Michael Sperber) Date: Wed, 14 Sep 2016 09:47:51 +0200 Subject: [erlang-questions] Call for Contributions: BOB 2017 - Berlin, Feb 24, 2017 Message-ID: BOB Conference 2017 "What happens when we use what's best for a change?" http://bobkonf.de/2017/en/cfp.html Berlin, February 24 Call for Contributions Deadline: October 30, 2016 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - ... everything really that isn?t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. This time, we?re especially interested in experience reports. But this could also take other forms, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - an abstract of max. 1500 characters. - a short bio/cv - contact information (including at least email address) - a list of 3-5 concrete ideas of how your work can be applied in a developer?s daily life -additional material (websites, blogs, slides, videos of past presentations, ?) Submit here: https://docs.google.com/forms/d/e/1FAIpQLSfFuyBhBTCOTS0zTXBzY1KVuKpumyIBTucLcJ1ArC1XpWsG-Q/viewform Organisation - direct questions to bobkonf at active minus group dot de - proposal deadline: October 30, 2016 - notification: November 15, 2016 - program: December 1, 2016 NOTE: The conference fee will be waived for presenters, but travel expenses will not be covered. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Details are here: http://bobkonf.de/2017/en/speaker-grants.html Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Program Committee ----------------- (more information here: http://bobkonf.de/2017/programmkomitee.html) - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni T?bingen - Peter Thiemann, Uni Freiburg From aschultz@REDACTED Wed Sep 14 15:12:53 2016 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 14 Sep 2016 15:12:53 +0200 (CEST) Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: References: <1443597593.75945.1473840539093.JavaMail.zimbra@tpip.net> Message-ID: <1391360787.81493.1473858773802.JavaMail.zimbra@tpip.net> Hi Oliver, Test suite was simple enough, so I made the RC4 fix into a real pull request: https://github.com/erlang/otp/pull/1169 Andreas ----- Original Message ----- > From: "Oliver Korpilla" > To: "Luis Rasc?o" > Cc: "erlang-questions" > Sent: Wednesday, September 14, 2016 12:39:40 PM > Subject: Re: [erlang-questions] Compiling Erlang without RC4? > Hello, Luis. > > Yes, I thought about building Erlang on a more "full-featured" machine and > deploying it as a statically linked binary as alternate solution. > > Since we rely on SCTP support in the kernel, however, my personal guess would be > that this is a little risky but doable and will require testing if all features > still work properly on target. > > So, yes, this would have been our next option to pursue. :) > > Thanks, > Oliver >? > > Gesendet:?Mittwoch, 14. September 2016 um 10:15 Uhr > Von:?"Luis Rasc?o" > An:?"Andreas Schultz" > Cc:?"Oliver Korpilla" , erlang-questions > > Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? > > You could build OpenSSL yourself and link statically link Erlang with it, would > that work also maybe? >? > On Wed, Sep 14, 2016 at 9:08 AM, Andreas Schultz wrote:Hi > Oliver, > > You could try the attached patch. This just disables the rc4 support, > for a pull request, some adjustments to the test suite might be > required as well. > > I don't have a OpenSSL without RC4, so this is purely guesswork! > > Andreas > > ----- Original Message ----- >> From: "Oliver Korpilla" >> To: "Alexander F?r?y" >> Cc: "erlang-questions" >> >> Sent: Tuesday, September 13, 2016 11:03:03 PM >> Subject: Re: [erlang-questions] Compiling Erlang without RC4? > >> Hello, Alexander. >> >> You misunderstand... I'm not concerned at all. The Linux distribution I have to >> work with removed the rc4.h header and without it I can not compile the Erlang >> runtime environment (and not deploy my application). >> >> I did a cursory look but it is as you say - I found no guards and there were >> plenty of references towards definitions from that header, so I was a bit out >> on a limb to ask if anything knew a trick to compile the Erlang runtime without >> this header... >> >> Thanks, >> Oliver >>? >>? >> >> Gesendet:?Dienstag, 13. September 2016 um 20:42 Uhr >> Von:?"Alexander F?r?y" >> An:?erlang-questions >> Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? >> On 13 September 2016 at 17:16, Oliver Korpilla >> wrote: >>> We currently have to work with a system where somebody thought removing rc4.h >>> would solve the security issues involved with this weak algorithm... >>> >>> Is there any way to build Erlang without RC4 (but still with crypto >>> functionality)? >> >> It doesn't look like the RC4 functionality is hidden behind a guard in >> the C source code, but I don't think you should be overly worried >> about using an Erlang release that contains RC4 support. >> >> If you take a look at the ciphers that the SSL application will use by >> default, you will see that there's no RC4 ciphers included (at least >> not in my OTP-18 installation locally): >> >> lists:foreach(fun (Suite) -> io:format("~p~n", [Suite]) end, >> ssl:cipher_suites()). >> >> You could consider filtering out the 3DES ciphers that are enabled by >> default though[1] using the {ciphers, [...]} option for SSL >> connections. >> >> Cheers, >> Alex. >> >> [1]: https://sweet32.info[https://sweet32.info] >> >> >> -- >> Alexander F?r?y >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED[erlang-questions@REDACTED] >> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions][http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]] >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED[erlang-questions@REDACTED] >> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED[erlang-questions@REDACTED] > http://erlang.org/mailman/listinfo/erlang-questions >?? >?-- > > PGP fingerprint:?F708 E141 AE8D 2D38 E1BC ?DF3D 1719 3EA0 647D 7260 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From henrik.x.nord@REDACTED Wed Sep 14 15:24:03 2016 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Wed, 14 Sep 2016 15:24:03 +0200 Subject: [erlang-questions] Patch package OTP 19.0.7 released Message-ID: <345635e3-e570-b9b5-c95f-224458cc1c2a@ericsson.com> Patch Package: OTP 19.0.7 Git Tag: OTP-19.0.7 Date: 2016-09-14 Trouble Report Id: OTP-13890 Seq num: System: OTP Release: 19 Application: erts-8.0.5 Predecessor: OTP 19.0.6 Check out the git tag OTP-19.0.7, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- erts-8.0.5 ------------------------------------------------------ --------------------------------------------------------------------- The erts-8.0.5 application can be applied independently of other applications on a full OTP 19 installation. --- Fixed Bugs and Malfunctions --- OTP-13890 Application(s): erts Fixed a VM crash that occured in a garbage collection of a process when it had received binaries. This bug was introduced in ERTS version 8.0 (OTP 19.0). Full runtime dependencies of erts-8.0.5: kernel-5.0, sasl-3.0, stdlib-3.0 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From dmkolesnikov@REDACTED Wed Sep 14 19:20:06 2016 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 14 Sep 2016 20:20:06 +0300 Subject: [erlang-questions] Stopping a process with its supervision subtree In-Reply-To: References: Message-ID: <92DCBCE1-B759-4E50-86FA-DC7488632A52@gmail.com> Hello, This is a good question! I?d like to get other's opinion on the subject as well. I would go with following pattern: * S_X is {one_for_all, 0, 1} and all its child are permanent. * The process P_2 just {stop, normal, State} when the job is done. I do not like to ?leak? a knowledge of supervisor to child processes. I?ll try to avoid usage of supervisor:terminate_child(?). On another hand, this pattern has disadvantage. You?ll see a ?supervisor? S_X crash in the log when P_2 stops due to ?permanent? property. The usage of simple_one_to_one supervisor seems to be right for this type of use-cases but it misses concept of related processes. What do you think? Best Regards, Dmitry > On Sep 14, 2016, at 11:42 AM, Karolis Petrauskas wrote: > > Hello, > > In my application I have a processes (lets say P_X), that are started > by starting a dedicated supervisor (S_X), which starts the process P_X > and several related processes as its children. The S_X supervisors are > started under the one_for_one supervisor (say MainSup). The > supervision tree schematically looks as the following for two P_X > started, when X = 1..2. > > MainSup > * S_1 > * P_1 > * Other_1 > * S_2 > * P_2 > * Other_2 > > I need to stop the entire supervisor S_X when the process P_X is done > with its job. > > Is it OK to call supervisor:stop_child(MainSup, X) from P_X process? I > experimented with that and it works. Just I'm now not sure, if this is > a correct way for doing that. The following is an excerpt from the > P_X: > > handle_info(deadline, State = #state{x = X}) -> > ok = supervisor:terminate_child(MainSup, X), > io:format("Stopped ~p~n", [X]), > {stop, normal, State}; > > The last two lines are not executed, as the supervisor:terminate_child > is synchronous and returns only after the P_X is terminated. > > Another option, as I understand, would be to start a process above the > MainSup and monitor all P_X processes and then stop the corresponding > supervisors S_X when the DOWN messages are received. Although I would > like to avoid creating such processes as well as to implement own > supervisor. > > Karolis > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From devangana@REDACTED Wed Sep 14 20:41:44 2016 From: devangana@REDACTED (Devangana Tarafdar) Date: Wed, 14 Sep 2016 13:41:44 -0500 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> Message-ID: Hi Dominik, So I was able look at the wireshark stream decoded after entering snmp credentials (that was very helpful, thanks !) and compared the 2 streams : One from the snmp get tool and the other from the erlang script. Wireshark is not able to decode the encrypted pdu in the erlang stream but it can decode the snmpget stream. The message is clear enough I suppose but I don't know what I am doing wrong with the key. I changed my local key generation to : %Priv_key_local = snmp:passwd2localized_key(sha, Priv_key , Agent_engine_id), % since auth protocol is SHA Priv_key_local = lists:sublist(snmp:passwd2localized_key(sha, Priv_key , Agent_engine_id),16), but it did not help. msgData: encryptedPDU (1) encryptedPDU: 8a3e7fc633c531d2747782a6fc8d89187c452929426e4b6e... Decrypted data not formatted as expected, wrong key? [Expert Info (Warn/Malformed): Decrypted data not formatted as expected] [Message: Decrypted data not formatted as expected] [Severity level: Warn] [Group: Malformed] Attaching good wireshark trace from snmpget and a bad one from erlang. Also tried putting a context name but did not work but snmpget does not put one and it works. Thanks, Devangana On Sun, Sep 11, 2016 at 4:09 PM, Devangana Tarafdar wrote: > Hi Dominik, > > I have not looked into the context. Will check all the items that you > mention. I have been able to connect to the agent using snmpwalk and > snmpget though I have not studied the wireshark output of those in detail. > Thanks again for all these tips and I will get back to you . > > Devangana > > On Sep 11, 2016 3:08 PM, "Dominik Pawlak" > wrote: > >> Hello Devangana, >> Hard to tell, but I see that you haven't specified any context in your >> sync_get. Are you sure it is not needed? I would also double check the >> engine id and security configuration. >> Have you managed to connect to that agent from something other than OTP >> (say snmpb, snmpget)? >> If so, you can compare in Wireshark, the snmp requests from erlang and >> from that tool. You can even enter your snmp credentials in Wireshark and >> it will decode encrypted messages. >> I hope any of this helps. >> >> Best >> Dominik >> >> On 11.09.2016 16:46, Devangana Tarafdar wrote: >> >> Hello Dominik, >> >> Thanks you for the reply. >> >> I sent another sync_get after the first as you suggested. The wireshark >> trace shows the manager has updated the 'msgAuthoritativeEngineBoots' >> and 'msgAuthoritativeEngineTime' to the values sent by the Agent as you >> pointed out. But now the agent does not respond at all and the sync_get >> fails with a timeout. I tried adding a second's sleep between the 2 gets as >> well. I don't have access currently to the agent's logs or configuration >> but have you seen this before ? >> >> Thanks ! >> Devangana >> >> >> On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak < >> dominik_pawlak@REDACTED> wrote: >> >>> Hello Devangana, >>> Basically, you just have to perform the sync_get once more. I observed >>> similar behavior in OTP 17.1 (snmp 4.25.1). The first request will always >>> fail because the manager is not fully configured to communicate with the >>> agent (more on that below). >>> >>> A longer explanation: >>> >>> In snmp v3 there is a process called 'discovery', which should be >>> performed before secure communication with the agent can be established. It >>> is described here: >>> >>> https://tools.ietf.org/html/rfc3414#section-4 >>> >>> The snmp library in OTP does not implement that process (at least not as >>> described in the RFC). >>> This process has two steps: 'snmpEngineID discovery' and 'time >>> synchronization'. >>> The first step is skipped altogether in OTP - you have to provide engine >>> id upfront. >>> The second step is performed by the first request - it will always fail >>> with the 'usmStatsNotInTimeWindows' error report message, but it will set >>> the required 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' >>> in the manager. >>> >>> Best, >>> Dominik >>> >>> >>> On 10.09.2016 06:48, Devangana Tarafdar wrote: >>> >>> Hello, >>> >>> I am trying to connect to a third party SNMP agent, using snmp manager >>> (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running into a >>> problem where the agent is returning this error on the manager calling >>> sync_get: >>> >>> >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>> handle_snmp_report -> entry with >>> Domain: snmpUDPDomain >>> Addr: {{xx,xxx,xxx,xxx},161} >>> ReqId: 37078226 >>> Rep: {invalid_sec_info,[{sec_level,3,1}, >>> {request_id,37078226,2147483647}]} >>> Pdu: {pdu,report,2147483647,noError,0, >>> [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** >>> handle_snmp_report -> found corresponding request: >>> reply to sync request >>> Ref: #Ref<0.0.4.210> >>> ModRef: #Ref<0.0.4.211> >>> From: {<0.3.0>,#Ref<0.0.4.202>} >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>> handle_snmp_pdu(get-response) -> Remaining: 4979 >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>> handle_snmp_report -> deliver reply >>> >>> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226, >>> 2147483647}],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0 >>> ],'Counter32',33,1}]}}} >>> >>> *** [2016:09:08 21:26:00 831] >>> >>> Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" (from >>> http://www.oid-info.com/) >>> >>> I have attached a wireshark trace for the snmp part of this exchange. >>> >>> I am invoking the snmpm module functions through a basic script as >>> follows (using tips from the tutorial at >>> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) >>> ......... >>> .......... >>> >>> ok = application:start(crypto), >>> ok = application:start(snmp), >>> >>> Userid = "snmp3user", >>> Agent_target = "testagent", >>> Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], >>> Agent_ip = {xx,xxx,xxx,xxx}, >>> Agent_port = 161 , >>> Secure_name= Userid, >>> >>> Security_level = 'authPriv', >>> Security_model = 'usm', >>> Agent_version = 'v3', >>> Auth_protocol = 'usmHMACSHAAuthProtocol', >>> Priv_protocol = 'usmAesCfb128Protocol', >>> >>> % this is 16 in length >>> Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), >>> >>> % this is 20 in length >>> Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), >>> >>> ok = snmpm:register_user(Userid,snmpm_user_default,[]), >>> >>> ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ >>> {auth, Auth_protocol}, >>> {auth_key,Auth_key_local}, >>> {priv, Priv_protocol}, >>> {priv_key,Priv_key_local }, >>> {sec_name, Secure_name} >>> ]), >>> ok = snmpm:register_agent(Userid, Agent_target ,[ >>> {engine_id,Agent_engine_id}, >>> {address, Agent_ip}, >>> {port, Agent_port}, >>> {version,Agent_version}, >>> {sec_model,Security_model}, >>> {sec_name,Secure_name}, >>> {sec_level, Security_level} >>> >>> ]), >>> Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), ........................ >>> >>> ........................ >>> >>> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! >>> >>> Thanks, Devangana >>> >>> _______________________________________________ >>> erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- No. Time Source Destination Protocol Length Info 1 2016-09-12 11:17:20.591800 xx.xx.xx.xx xx.xx.xx.xx SNMP 106 get-request Frame 1: 106 bytes on wire (848 bits), 106 bytes captured (848 bits) Ethernet II, Src: Dell_5a:bb:91 (xxxxxxxxxx), Dst: Cisco_ea:e8:00 (xxxxxxxxxxxx) Internet Protocol Version 4, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: xx.xx.xx.xx (xx.xx.xx.xx) User Datagram Protocol, Src Port: 56064 (56064), Dst Port: snmp (161) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 1249727467 msgMaxSize: 65507 msgFlags: 04 msgSecurityModel: USM (3) msgAuthoritativeEngineID: msgAuthoritativeEngineBoots: 0 msgAuthoritativeEngineTime: 0 msgUserName: msgAuthenticationParameters: msgPrivacyParameters: msgData: plaintext (0) plaintext contextEngineID: contextName: data: get-request (0) get-request request-id: 157902137 error-status: noError (0) error-index: 0 variable-bindings: 0 items No. Time Source Destination Protocol Length Info 2 2016-09-12 11:17:20.603244 xx.xx.xx.xx xx.xx.xx.xx SNMP 151 report 1.3.6.1.6.3.15.1.1.4.0 Frame 2: 151 bytes on wire (1208 bits), 151 bytes captured (1208 bits) Ethernet II, Src: Cisco_ea:e8:00 (xxxxxxxxxxxx), Dst: Dell_5a:bb:91 (xxxxxxxxxx) Internet Protocol Version 4, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: xx.xx.xx.xx (xx.xx.xx.xx) User Datagram Protocol, Src Port: snmp (161), Dst Port: 56064 (56064) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 1249727467 msgMaxSize: 1500 msgFlags: 00 msgSecurityModel: USM (3) msgAuthoritativeEngineID: xxxxxxxxxxxxxxxxxxxxx msgAuthoritativeEngineBoots: 3 msgAuthoritativeEngineTime: 57959463 msgUserName: msgAuthenticationParameters: msgPrivacyParameters: msgData: plaintext (0) plaintext contextEngineID: xxxxxxxxxxxxxxxxxxxxx contextName: data: report (8) report request-id: 157902137 error-status: noError (0) error-index: 0 variable-bindings: 1 item No. Time Source Destination Protocol Length Info 3 2016-09-12 11:17:20.603411 xx.xx.xx.xx xx.xx.xx.xx SNMP 186 get-request 1.3.6.1.4.1.9.10.19.1.1.9.1.3.7.2 Frame 3: 186 bytes on wire (1488 bits), 186 bytes captured (1488 bits) Ethernet II, Src: Dell_5a:bb:91 (xxxxxxxxxx), Dst: Cisco_ea:e8:00 (xxxxxxxxxxxx) Internet Protocol Version 4, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: xx.xx.xx.xx (xx.xx.xx.xx) User Datagram Protocol, Src Port: 56064 (56064), Dst Port: snmp (161) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 1249727466 msgMaxSize: 65507 msgFlags: 07 msgSecurityModel: USM (3) msgAuthoritativeEngineID: xxxxxxxxxxxxxxxxxxxxx msgAuthoritativeEngineBoots: 3 msgAuthoritativeEngineTime: 57959463 msgUserName: snmp3user msgAuthenticationParameters: 66066a5c8bb770ac44a8a6aa [Authentication: OK] [Expert Info (Chat/Checksum): SNMP Authentication OK] [Message: SNMP Authentication OK] [Severity level: Chat] [Group: Checksum] msgPrivacyParameters: 7659ce996f84ed61 msgData: encryptedPDU (1) encryptedPDU: 2fd50fd5753850f7a6a098056cd9b062770b96b4a9658469... Decrypted ScopedPDU: 3035040cxxxxxxxxxxxxxxxxxxxxx0400a02302040969... contextEngineID: xxxxxxxxxxxxxxxxxxxxx contextName: data: get-request (0) get-request request-id: 157902136 error-status: noError (0) error-index: 0 variable-bindings: 1 item No. Time Source Destination Protocol Length Info 4 2016-09-12 11:17:20.614562 xx.xx.xx.xx xx.xx.xx.xx SNMP 186 get-response 1.3.6.1.4.1.9.10.19.1.1.9.1.3.7.2 Frame 4: 186 bytes on wire (1488 bits), 186 bytes captured (1488 bits) Ethernet II, Src: Cisco_ea:e8:00 (xxxxxxxxxxxx), Dst: Dell_5a:bb:91 (xxxxxxxxxx) Internet Protocol Version 4, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: xx.xx.xx.xx (xx.xx.xx.xx) User Datagram Protocol, Src Port: snmp (161), Dst Port: 56064 (56064) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 1249727466 msgMaxSize: 1500 msgFlags: 03 msgSecurityModel: USM (3) msgAuthoritativeEngineID:xxxxxxxxxxxxxxxxxxxxx msgAuthoritativeEngineBoots: 3 msgAuthoritativeEngineTime: 57959463 msgUserName: snmp3user msgAuthenticationParameters: c9a294d040e72dc862a552d9 [Authentication: OK] [Expert Info (Chat/Checksum): SNMP Authentication OK] [Message: SNMP Authentication OK] [Severity level: Chat] [Group: Checksum] msgPrivacyParameters: 03acf687bd16cbb9 msgData: encryptedPDU (1) encryptedPDU: 7bf96b26eb9009354008da4fd46a6ab68323a757bb5bd009... Decrypted ScopedPDU: 3036040cxxxxxxxxxxxxxxxxxxxxx0400a22402040969... contextEngineID: xxxxxxxxxxxxxxxxxxxxx contextName: data: get-response (2) get-response request-id: 157902136 error-status: noError (0) error-index: 0 variable-bindings: 1 item -------------- next part -------------- No. Time Source Destination Protocol Length Info 1 2016-09-14 12:52:45.116572 xx.xx.xx.xx xx.xx.xx.xx SNMP 182 encryptedPDU: Decrypted data not formatted as expected Frame 1: 182 bytes on wire (1456 bits), 182 bytes captured (1456 bits) Ethernet II, Src: Dell_5a:bb:91 (xx.xx.xx.xx), Dst: Cisco_ea:e8:00 (xx.xx.xx.xx.xx) Internet Protocol Version 4, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: xx.xx.xx.xx (xx.xx.xx.xx) User Datagram Protocol, Src Port: commplex-main (5000), Dst Port: snmp (161) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 991281567 msgMaxSize: 484 msgFlags: 07 msgSecurityModel: USM (3) msgAuthoritativeEngineID: xxxxxxxxxxxxxxxxxxxxxx msgAuthoritativeEngineBoots: 0 msgAuthoritativeEngineTime: 0 msgUserName: snmp3user msgAuthenticationParameters: c7f951adc5fdb07861e75897 [Authentication: OK] [Expert Info (Chat/Checksum): SNMP Authentication OK] [Message: SNMP Authentication OK] [Severity level: Chat] [Group: Checksum] msgPrivacyParameters: 0000000000000001 msgData: encryptedPDU (1) encryptedPDU: 8a3e7fc633c531d2747782a6fc8d89187c452929426e4b6e... Decrypted data not formatted as expected, wrong key? [Expert Info (Warn/Malformed): Decrypted data not formatted as expected] [Message: Decrypted data not formatted as expected] [Severity level: Warn] [Group: Malformed] No. Time Source Destination Protocol Length Info 2 2016-09-14 12:52:45.128530 xx.xx.xx.xx xx.xx.xx.xx SNMP 170 report 1.3.6.1.6.3.15.1.1.2.0 Frame 2: 170 bytes on wire (1360 bits), 170 bytes captured (1360 bits) Ethernet II, Src: Cisco_ea:e8:00 (xx.xx.xx.xx.xx), Dst: Dell_5a:bb:91 (xx.xx.xx.xx) Internet Protocol Version 4, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: xx.xx.xx.xx (xx.xx.xx.xx) User Datagram Protocol, Src Port: snmp (161), Dst Port: commplex-main (5000) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 991281567 msgMaxSize: 1500 msgFlags: 01 msgSecurityModel: USM (3) msgAuthoritativeEngineID: xxxxxxxxxxxxxxxxxxxxxx msgAuthoritativeEngineBoots: 3 msgAuthoritativeEngineTime: 58137986 msgUserName: snmp3user msgAuthenticationParameters: 8b04a985942e50bb852e12c2 [Authentication: OK] [Expert Info (Chat/Checksum): SNMP Authentication OK] [Message: SNMP Authentication OK] [Severity level: Chat] [Group: Checksum] msgPrivacyParameters: msgData: plaintext (0) plaintext No. Time Source Destination Protocol Length Info 3 2016-09-14 12:52:46.137742 xx.xx.xx.xx xx.xx.xx.xx SNMP 185 Source port: commplex-main Destination port: snmp[Malformed Packet] Frame 3: 185 bytes on wire (1480 bits), 185 bytes captured (1480 bits) Ethernet II, Src: Dell_5a:bb:91 (xx.xx.xx.xx), Dst: Cisco_ea:e8:00 (xx.xx.xx.xx.xx) Internet Protocol Version 4, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: xx.xx.xx.xx (xx.xx.xx.xx) User Datagram Protocol, Src Port: commplex-main (5000), Dst Port: snmp (161) Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 991281568 msgMaxSize: 484 msgFlags: 07 msgSecurityModel: USM (3) msgAuthoritativeEngineID: xxxxxxxxxxxxxxxxxxxxxx msgAuthoritativeEngineBoots: 3 msgAuthoritativeEngineTime: 58137987 msgUserName: snmp3user msgAuthenticationParameters: faf88ff2c55fead30027041c msgPrivacyParameters: 0000000000000002 msgData: encryptedPDU (1) encryptedPDU: 1cdd0c3bcd32afc23beacca094272afba52babb364bc2d65... [Malformed Packet: SNMP] [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)] [Message: Malformed Packet (Exception occurred)] [Severity level: Error] [Group: Malformed] From dominik_pawlak@REDACTED Wed Sep 14 22:52:33 2016 From: dominik_pawlak@REDACTED (Dominik Pawlak) Date: Wed, 14 Sep 2016 22:52:33 +0200 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> Message-ID: Hi Devangana, I see that you use AES for encryption. There was a related bug in the snmp library: http://erlang.org/pipermail/erlang-bugs/2014-August/004551.html I don't know if it's fixed in newer snmp library versions. I attached the patch that we used to fix snmp 4.25.1. Or maybe you can live with DES encryption? Best Dominik On 14.09.2016 20:41, Devangana Tarafdar wrote: > Hi Dominik, > > So I was able look at the wireshark stream decoded after entering snmp > credentials (that was very helpful, thanks !) and compared the 2 > streams : One from the snmp get tool and the other from the erlang script. > > Wireshark is not able to decode the encrypted pdu in the erlang > stream but it can decode the snmpget stream. > > The message is clear enough I suppose but I don't know what I am doing > wrong with the key. > > I changed my local key generation to : > > %Priv_key_local = snmp:passwd2localized_key(sha, Priv_key , > Agent_engine_id), > > % since auth protocol is SHA > Priv_key_local = lists:sublist(snmp:passwd2localized_key(sha, > Priv_key , Agent_engine_id),16), > > but it did not help. > > > msgData: encryptedPDU (1) > encryptedPDU: 8a3e7fc633c531d2747782a6fc8d89187c452929426e4b6e... > Decrypted data not formatted as expected, wrong key? > [Expert Info (Warn/Malformed): Decrypted data not > formatted as expected] > [Message: Decrypted data not formatted as expected] > [Severity level: Warn] > [Group: Malformed] > > > Attaching good wireshark trace from snmpget and a bad one from erlang. > > Also tried putting a context name but did not work but snmpget does > not put one and it works. > > Thanks, > Devangana > > > > On Sun, Sep 11, 2016 at 4:09 PM, Devangana Tarafdar > > wrote: > > Hi Dominik, > > I have not looked into the context. Will check all the items that > you mention. I have been able to connect to the agent using > snmpwalk and snmpget though I have not studied the wireshark > output of those in detail. > Thanks again for all these tips and I will get back to you . > > Devangana > > > On Sep 11, 2016 3:08 PM, "Dominik Pawlak" > > > wrote: > > Hello Devangana, > Hard to tell, but I see that you haven't specified any context > in your sync_get. Are you sure it is not needed? I would also > double check the engine id and security configuration. > Have you managed to connect to that agent from something other > than OTP (say snmpb, snmpget)? > If so, you can compare in Wireshark, the snmp requests from > erlang and from that tool. You can even enter your snmp > credentials in Wireshark and it will decode encrypted messages. > I hope any of this helps. > > Best > Dominik > > On 11.09.2016 16:46, Devangana Tarafdar wrote: >> Hello Dominik, >> >> Thanks you for the reply. >> >> I sent another sync_get after the first as you suggested. >> The wireshark trace shows the manager has updated the >> 'msgAuthoritativeEngineBoots' and >> 'msgAuthoritativeEngineTime' to the values sent by the Agent >> as you pointed out. But now the agent does not respond at all >> and the sync_get fails with a timeout. I tried adding a >> second's sleep between the 2 gets as well. I don't have >> access currently to the agent's logs or configuration but >> have you seen this before ? >> >> Thanks ! >> Devangana >> >> >> On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak >> > > wrote: >> >> Hello Devangana, >> Basically, you just have to perform the sync_get once >> more. I observed similar behavior in OTP 17.1 (snmp >> 4.25.1). The first request will always fail because the >> manager is not fully configured to communicate with the >> agent (more on that below). >> >> A longer explanation: >> >> In snmp v3 there is a process called 'discovery', which >> should be performed before secure communication with the >> agent can be established. It is described here: >> >> https://tools.ietf.org/html/rfc3414#section-4 >> >> >> The snmp library in OTP does not implement that process >> (at least not as described in the RFC). >> This process has two steps: 'snmpEngineID discovery' and >> 'time synchronization'. >> The first step is skipped altogether in OTP - you have to >> provide engine id upfront. >> The second step is performed by the first request - it >> will always fail with the 'usmStatsNotInTimeWindows' >> error report message, but it will set the required >> 'msgAuthoritativeEngineBoots' and >> 'msgAuthoritativeEngineTime' in the manager. >> >> Best, >> Dominik >> >> >> On 10.09.2016 06:48, Devangana Tarafdar wrote: >>> Hello, >>> >>> I am trying to connect to a third party SNMP agent, >>> using snmp manager (snmp v3) ( in the erlang 19 release >>> snmp 5.2.3) and I am running into a problem where the >>> agent is returning this error on the manager calling >>> sync_get: >>> >>> >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>> handle_snmp_report -> entry with >>> Domain: snmpUDPDomain >>> Addr: {{xx,xxx,xxx,xxx},161} >>> ReqId: 37078226 >>> Rep: {invalid_sec_info,[{sec_level,3,1}, >>> {request_id,37078226,2147483647 }]} >>> Pdu: {pdu,report,2147483647 ,noError,0, >>> [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** >>> handle_snmp_report -> found corresponding request: >>> reply to sync request >>> Ref: #Ref<0.0.4.210> >>> ModRef: #Ref<0.0.4.211> >>> From: {<0.3.0>,#Ref<0.0.4.202>} >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>> handle_snmp_pdu(get-response) -> Remaining: 4979 >>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>> handle_snmp_report -> deliver reply >>> >>> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226,2147483647 >>> }],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]}}} >>> >>> *** [2016:09:08 21:26:00 831] >>> >>> Where [1,3,6,1,6,3,15,1,1,2,0] maps to >>> "usmStatsNotInTimeWindows" (from http://www.oid-info.com/) >>> >>> I have attached a wireshark trace for the snmp part of >>> this exchange. >>> >>> I am invoking the snmpm module functions through a basic >>> script as follows (using tips from the tutorial at >>> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start >>> >>> ) >>> ......... >>> .......... >>> ok = application:start(crypto), >>> ok = application:start(snmp), >>> >>> Userid = "snmp3user", >>> Agent_target = "testagent", >>> Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], >>> Agent_ip = {xx,xxx,xxx,xxx}, >>> Agent_port = 161 , >>> Secure_name= Userid, >>> >>> Security_level = 'authPriv', >>> Security_model = 'usm', >>> Agent_version = 'v3', >>> Auth_protocol = 'usmHMACSHAAuthProtocol', >>> Priv_protocol = 'usmAesCfb128Protocol', >>> >>> % this is 16 in length >>> Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), >>> >>> % this is 20 in length >>> Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), >>> >>> ok = snmpm:register_user(Userid,snmpm_user_default,[]), >>> ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ >>> {auth, Auth_protocol}, >>> {auth_key,Auth_key_local}, >>> {priv, Priv_protocol}, >>> {priv_key,Priv_key_local }, >>> {sec_name, Secure_name} >>> ]), >>> ok = snmpm:register_agent(Userid, Agent_target ,[ >>> {engine_id,Agent_engine_id}, >>> {address, Agent_ip}, >>> {port, Agent_port}, >>> {version,Agent_version}, >>> {sec_model,Security_model}, >>> {sec_name,Secure_name}, >>> {sec_level, Security_level} >>> ]), >>> Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), >>> ........................ >>> ........................ >>> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! >>> Thanks, Devangana >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snmp.patch Type: text/x-patch Size: 4555 bytes Desc: not available URL: From Oliver.Korpilla@REDACTED Wed Sep 14 23:18:15 2016 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Wed, 14 Sep 2016 23:18:15 +0200 Subject: [erlang-questions] Compiling Erlang without RC4? In-Reply-To: <1391360787.81493.1473858773802.JavaMail.zimbra@tpip.net> References: <1443597593.75945.1473840539093.JavaMail.zimbra@tpip.net> , <1391360787.81493.1473858773802.JavaMail.zimbra@tpip.net> Message-ID: Hello, Andreas. It is appreciated. :) Thanks, Oliver ? Gesendet:?Mittwoch, 14. September 2016 um 15:12 Uhr Von:?"Andreas Schultz" An:?"Oliver Korpilla" Cc:?erlang-questions Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? Hi Oliver, Test suite was simple enough, so I made the RC4 fix into a real pull request: https://github.com/erlang/otp/pull/1169 Andreas ----- Original Message ----- > From: "Oliver Korpilla" > To: "Luis Rasc?o" > Cc: "erlang-questions" > Sent: Wednesday, September 14, 2016 12:39:40 PM > Subject: Re: [erlang-questions] Compiling Erlang without RC4? > Hello, Luis. > > Yes, I thought about building Erlang on a more "full-featured" machine and > deploying it as a statically linked binary as alternate solution. > > Since we rely on SCTP support in the kernel, however, my personal guess would be > that this is a little risky but doable and will require testing if all features > still work properly on target. > > So, yes, this would have been our next option to pursue. :) > > Thanks, > Oliver >? > > Gesendet:?Mittwoch, 14. September 2016 um 10:15 Uhr > Von:?"Luis Rasc?o" > An:?"Andreas Schultz" > Cc:?"Oliver Korpilla" , erlang-questions > > Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? > > You could build OpenSSL yourself and link statically link Erlang with it, would > that work also maybe? >? > On Wed, Sep 14, 2016 at 9:08 AM, Andreas Schultz wrote:Hi > Oliver, > > You could try the attached patch. This just disables the rc4 support, > for a pull request, some adjustments to the test suite might be > required as well. > > I don't have a OpenSSL without RC4, so this is purely guesswork! > > Andreas > > ----- Original Message ----- >> From: "Oliver Korpilla" >> To: "Alexander F?r?y" >> Cc: "erlang-questions" >> >> Sent: Tuesday, September 13, 2016 11:03:03 PM >> Subject: Re: [erlang-questions] Compiling Erlang without RC4? > >> Hello, Alexander. >> >> You misunderstand... I'm not concerned at all. The Linux distribution I have to >> work with removed the rc4.h header and without it I can not compile the Erlang >> runtime environment (and not deploy my application). >> >> I did a cursory look but it is as you say - I found no guards and there were >> plenty of references towards definitions from that header, so I was a bit out >> on a limb to ask if anything knew a trick to compile the Erlang runtime without >> this header... >> >> Thanks, >> Oliver >>? >>? >> >> Gesendet:?Dienstag, 13. September 2016 um 20:42 Uhr >> Von:?"Alexander F?r?y" >> An:?erlang-questions >> Betreff:?Re: [erlang-questions] Compiling Erlang without RC4? >> On 13 September 2016 at 17:16, Oliver Korpilla >> wrote: >>> We currently have to work with a system where somebody thought removing rc4.h >>> would solve the security issues involved with this weak algorithm... >>> >>> Is there any way to build Erlang without RC4 (but still with crypto >>> functionality)? >> >> It doesn't look like the RC4 functionality is hidden behind a guard in >> the C source code, but I don't think you should be overly worried >> about using an Erlang release that contains RC4 support. >> >> If you take a look at the ciphers that the SSL application will use by >> default, you will see that there's no RC4 ciphers included (at least >> not in my OTP-18 installation locally): >> >> lists:foreach(fun (Suite) -> io:format("~p~n", [Suite]) end, >> ssl:cipher_suites()). >> >> You could consider filtering out the 3DES ciphers that are enabled by >> default though[1] using the {ciphers, [...]} option for SSL >> connections. >> >> Cheers, >> Alex. >> >> [1]: https://sweet32.info[https://sweet32.info][https://sweet32.info[https://sweet32.info]] >> >> >> -- >> Alexander F?r?y >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED[erlang-questions@REDACTED] >> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions][http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]][http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions][http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]]] >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED[erlang-questions@REDACTED] >> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions][http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]] > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED[erlang-questions@REDACTED] > http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] >?? >?-- > > PGP fingerprint:?F708 E141 AE8D 2D38 E1BC ?DF3D 1719 3EA0 647D 7260 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] From felixgallo@REDACTED Thu Sep 15 03:49:24 2016 From: felixgallo@REDACTED (Felix Gallo) Date: Wed, 14 Sep 2016 18:49:24 -0700 Subject: [erlang-questions] setting up distribution between a local node and a firewalled node Message-ID: If you were to believe https://gist.github.com/pnc/9e957e17d4f9c6c81294, setting up distribution between a local node and a firewalled node would be as simple as: 1) proxying a connection to the epmd running on the firewalled node so that your local port 4369 connects to the firewalled node's epmd 2) running 'epmd -names' to identify the distribution port that the firewalled node is using 3) proxying that port too 4) CHANGING YOUR HOSTNAME TO MATCH THE REMOTE NODE'S HOSTNAME (!?) 5) starting up a local node 'debug@REDACTED' with the same cookie as that firewalled node, your local node then registering using the proxied epmd on 4369 6) running, e.g., 'net_adm:ping('target_node_name@REDACTED'). However, this doesn't seem to work, because I get pang. So many pangs. Regardless of how I try to qualify the node name. Some questions: a) step 4, that's, like, not actually how it has to happen, right? b) what am I likely to be missing? F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Thu Sep 15 04:46:22 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Wed, 14 Sep 2016 19:46:22 -0700 Subject: [erlang-questions] Patch package OTP 19.0.7 released In-Reply-To: <345635e3-e570-b9b5-c95f-224458cc1c2a@ericsson.com> References: <345635e3-e570-b9b5-c95f-224458cc1c2a@ericsson.com> Message-ID: On 09/14/2016 06:24 AM, Henrik Nord X wrote: > Patch Package: OTP 19.0.7 I did a bit of searching, but I seem to have missed any official documentation on the matter. So, some questions about Erlang versioning and patch packages: When the third component of the version number changes, does that indicate that that version was a patch package rather than a full release that gets its own tarball on erlang.org? (With the exception of 18.2.1.) For the foreseeable future, are the only Erlang releases that get source tarballs & etc. on erlang.org releases that increment the first or second component of the version number? (Or ones like 18.2.1 that fix _serious_ errors?) I notice that there were two separate patch packages released today, each containing a single fix. Was this simply a case of failing to include the fix for OTP-13890 in 19.0.6, or is there some reason why an Erlang user would want to install .6 rather than .7 that I'm missing? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lukas.larsson@REDACTED Thu Sep 15 07:32:27 2016 From: lukas.larsson@REDACTED (Lukas Larsson) Date: Thu, 15 Sep 2016 07:32:27 +0200 Subject: [erlang-questions] Patch package OTP 19.0.7 released In-Reply-To: References: <345635e3-e570-b9b5-c95f-224458cc1c2a@ericsson.com> Message-ID: <5851F85E-1EC5-478F-BD05-D30A0B68489B@erlang-solutions.com> Hello, > On 15 sep. 2016, at 04:46, Kenneth Lakin wrote: > >> On 09/14/2016 06:24 AM, Henrik Nord X wrote: >> Patch Package: OTP 19.0.7 > > I did a bit of searching, but I seem to have missed any official > documentation on the matter. > > So, some questions about Erlang versioning and patch packages: > > When the third component of the version number changes, does that > indicate that that version was a patch package rather than a full > release that gets its own tarball on erlang.org? (With the exception of > 18.2.1.) The versioning scheme that we use is described here: http://erlang.org/doc/system_principles/versions.html And yes, normally only major and minor releases get tarballs and Windows installers built and uploaded to erlang.org > > For the foreseeable future, are the only Erlang releases that get source > tarballs & etc. on erlang.org releases that increment the first or > second component of the version number? (Or ones like 18.2.1 that fix > _serious_ errors?) Yes > > I notice that there were two separate patch packages released today, > each containing a single fix. Was this simply a case of failing to > include the fix for OTP-13890 in 19.0.6, or is there some reason why an > Erlang user would want to install .6 rather than .7 that I'm missing? Sometimes that can be the reason, this time we found another bug about 10 minutes after doing the 19.0.6 release. > > Thanks! > > _______________________________________________ > 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 Thu Sep 15 10:28:17 2016 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 15 Sep 2016 10:28:17 +0200 Subject: [erlang-questions] reorder SSL certificate chain with Erlang 19 In-Reply-To: References: Message-ID: Hi! Please try this branch *IngelaAndin:ingela/ssl/unorded-cert-chain/OTP-12983 * It does not break existing code. But it is not prioritized to Ericsson, so I do not have the time to make a real test case at the moment. That would require me to either to craft a way to send it out of order or use some other implementation that does this.) Regards Ingela Erlang/OTP Team - Ericsson AB 2016-09-12 12:23 GMT+02:00 Benoit Chesneau : > Is there anyway now to reorder the certificate chain received with Erlang > 19 like browsers and most languages do by default. Maybe in an hackish way? > > It's actually the cause of many connection issue via http to some servers > and the response can't just be about asking the server owner to fix it. > Users expect that the connection will work as it is with curl. > > Any hint is appreciated :) > > - benoit > > _______________________________________________ > 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 Sep 15 11:43:14 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 15 Sep 2016 11:43:14 +0200 Subject: [erlang-questions] MyModule:start_link/? vs supervisor:start_link/3 In-Reply-To: References: Message-ID: On Tue, Sep 13, 2016 at 11:06 PM, Charles Shuller wrote: > Is there any advantage to specifying a custom start_link in the supervisor > callback module? It is often used to keep the "scope" of the calls consistent. If you have a call to e.g., gen_server:call/2 which is not inside the module defining the Module:handle_call/3 callback, then you are leaking information about the implementation to the outside caller and if you wish to switch to gen_statem later, you will have to find all call sites and change them. The same could be said for a call to supervisor. By keeping it local to the module, you encapsulate the information about the supervisor into a module on its own and that information doesn't leak outside. Granted, it is rarer you wish to switch a supervisor to something else, but I have had the need for this a couple of times. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vans_163@REDACTED Thu Sep 15 16:27:31 2016 From: vans_163@REDACTED (Vans S) Date: Thu, 15 Sep 2016 14:27:31 +0000 (UTC) Subject: [erlang-questions] A0 outperforming A>0, why? References: <1616165537.1589722.1473949651606.ref@mail.yahoo.com> Message-ID: <1616165537.1589722.1473949651606@mail.yahoo.com> Running the rebar3 test suite, ct, passing A0 to the VM args is consistently outperforming using any value of A above 0. The test suite does over 1m iops. This should not be the be the case, is not the whole point of async threads to improve io throughput? The test can be setup by doing: install a package called time (apt-get install time) git clone?https://github.com/erlang/rebar3.git rebar3 install localexport?REBAR3_ERL_ARGS="+A0 +K true"time -v $(LOCAL_INSTALL_REBAR3_BIN) ct export?REBAR3_ERL_ARGS="+A1 +K true"time -v $(LOCAL_INSTALL_REBAR3_BIN) ctexport?REBAR3_ERL_ARGS="+A100 +K true"time -v $(LOCAL_INSTALL_REBAR3_BIN) ct (rebar3 passes +sbtu as well) Here is an example of some results: %A0 Command being timed: "/home/user/.cache/rebar3/bin/rebar3 ct" User time (seconds): 203.63 System time (seconds): 12.12 Percent of CPU this job got: 128% Elapsed (wall clock) time (h:mm:ss or m:ss): 2:48.44 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 369744 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 2710315 Voluntary context switches: 215661 Involuntary context switches: 219472 Swaps: 0 File system inputs: 40 File system outputs: 1078936 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 %A1 Command being timed: "/home/user/.cache/rebar3/bin/rebar3 ct" User time (seconds): 221.73 System time (seconds): 17.73 Percent of CPU this job got: 134% Elapsed (wall clock) time (h:mm:ss or m:ss): 2:57.55 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 418184 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 2704281 Voluntary context switches: 2307583 Involuntary context switches: 306797 Swaps: 0 File system inputs: 48 File system outputs: 1078928 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 %A100 Command being timed: "/home/user/.cache/rebar3/bin/rebar3 ct" User time (seconds): 223.26 System time (seconds): 18.20 Percent of CPU this job got: 133% Elapsed (wall clock) time (h:mm:ss or m:ss): 3:01.20 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 385492 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 2651960 Voluntary context switches: 2392798 Involuntary context switches: 404162 Swaps: 0 File system inputs: 72 File system outputs: 1078936 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Thu Sep 15 17:52:26 2016 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 15 Sep 2016 15:52:26 +0000 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> Message-ID: Check that the engine ids are what you expect them to be. You've redacted all the engine ids from the trace, so I can't check them. The SNMP config files have trouble storing non-ascii engine ids; not sure if this affect you. This should be fixed agent-side for 19.1, not sure about manager-side. On Wed, Sep 14, 2016 at 1:42 PM Devangana Tarafdar wrote: > Hi Dominik, > > So I was able look at the wireshark stream decoded after entering snmp > credentials (that was very helpful, thanks !) and compared the 2 streams : > One from the snmp get tool and the other from the erlang script. > > Wireshark is not able to decode the encrypted pdu in the erlang stream > but it can decode the snmpget stream. > > The message is clear enough I suppose but I don't know what I am doing > wrong with the key. > > I changed my local key generation to : > > %Priv_key_local = snmp:passwd2localized_key(sha, Priv_key , > Agent_engine_id), > > % since auth protocol is SHA > Priv_key_local = lists:sublist(snmp:passwd2localized_key(sha, Priv_key , > Agent_engine_id),16), > > but it did not help. > > > msgData: encryptedPDU (1) > encryptedPDU: 8a3e7fc633c531d2747782a6fc8d89187c452929426e4b6e... > Decrypted data not formatted as expected, wrong key? > [Expert Info (Warn/Malformed): Decrypted data not > formatted as expected] > [Message: Decrypted data not formatted as expected] > [Severity level: Warn] > [Group: Malformed] > > > Attaching good wireshark trace from snmpget and a bad one from erlang. > > Also tried putting a context name but did not work but snmpget does not > put one and it works. > > Thanks, > Devangana > > > > On Sun, Sep 11, 2016 at 4:09 PM, Devangana Tarafdar > wrote: > >> Hi Dominik, >> >> I have not looked into the context. Will check all the items that you >> mention. I have been able to connect to the agent using snmpwalk and >> snmpget though I have not studied the wireshark output of those in detail. >> Thanks again for all these tips and I will get back to you . >> >> Devangana >> >> On Sep 11, 2016 3:08 PM, "Dominik Pawlak" >> wrote: >> >>> Hello Devangana, >>> Hard to tell, but I see that you haven't specified any context in your >>> sync_get. Are you sure it is not needed? I would also double check the >>> engine id and security configuration. >>> Have you managed to connect to that agent from something other than OTP >>> (say snmpb, snmpget)? >>> If so, you can compare in Wireshark, the snmp requests from erlang and >>> from that tool. You can even enter your snmp credentials in Wireshark and >>> it will decode encrypted messages. >>> I hope any of this helps. >>> >>> Best >>> Dominik >>> >>> On 11.09.2016 16:46, Devangana Tarafdar wrote: >>> >>> Hello Dominik, >>> >>> Thanks you for the reply. >>> >>> I sent another sync_get after the first as you suggested. The wireshark >>> trace shows the manager has updated the 'msgAuthoritativeEngineBoots' >>> and 'msgAuthoritativeEngineTime' to the values sent by the Agent as you >>> pointed out. But now the agent does not respond at all and the sync_get >>> fails with a timeout. I tried adding a second's sleep between the 2 gets as >>> well. I don't have access currently to the agent's logs or configuration >>> but have you seen this before ? >>> >>> Thanks ! >>> Devangana >>> >>> >>> On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak < >>> dominik_pawlak@REDACTED> wrote: >>> >>>> Hello Devangana, >>>> Basically, you just have to perform the sync_get once more. I observed >>>> similar behavior in OTP 17.1 (snmp 4.25.1). The first request will always >>>> fail because the manager is not fully configured to communicate with the >>>> agent (more on that below). >>>> >>>> A longer explanation: >>>> >>>> In snmp v3 there is a process called 'discovery', which should be >>>> performed before secure communication with the agent can be established. It >>>> is described here: >>>> >>>> https://tools.ietf.org/html/rfc3414#section-4 >>>> >>>> The snmp library in OTP does not implement that process (at least not >>>> as described in the RFC). >>>> This process has two steps: 'snmpEngineID discovery' and 'time >>>> synchronization'. >>>> The first step is skipped altogether in OTP - you have to provide >>>> engine id upfront. >>>> The second step is performed by the first request - it will always fail >>>> with the 'usmStatsNotInTimeWindows' error report message, but it will set >>>> the required 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' >>>> in the manager. >>>> >>>> Best, >>>> Dominik >>>> >>>> >>>> On 10.09.2016 06:48, Devangana Tarafdar wrote: >>>> >>>> Hello, >>>> >>>> I am trying to connect to a third party SNMP agent, using snmp manager >>>> (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running into a >>>> problem where the agent is returning this error on the manager calling >>>> sync_get: >>>> >>>> >>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>> handle_snmp_report -> entry with >>>> Domain: snmpUDPDomain >>>> Addr: {{xx,xxx,xxx,xxx},161} >>>> ReqId: 37078226 >>>> Rep: {invalid_sec_info,[{sec_level,3,1}, >>>> {request_id,37078226,2147483647}]} >>>> Pdu: {pdu,report,2147483647,noError,0, >>>> [{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]} >>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** >>>> handle_snmp_report -> found corresponding request: >>>> reply to sync request >>>> Ref: #Ref<0.0.4.210> >>>> ModRef: #Ref<0.0.4.211> >>>> From: {<0.3.0>,#Ref<0.0.4.202>} >>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>> handle_snmp_pdu(get-response) -> Remaining: 4979 >>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>> handle_snmp_report -> deliver reply >>>> >>>> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226, >>>> 2147483647 >>>> }],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,0],'Counter32',33,1}]}}} >>>> >>>> *** [2016:09:08 21:26:00 831] >>>> >>>> Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" >>>> (from http://www.oid-info.com/) >>>> >>>> I have attached a wireshark trace for the snmp part of this exchange. >>>> >>>> I am invoking the snmpm module functions through a basic script as >>>> follows (using tips from the tutorial at >>>> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) >>>> ......... >>>> .......... >>>> >>>> ok = application:start(crypto), >>>> ok = application:start(snmp), >>>> >>>> Userid = "snmp3user", >>>> Agent_target = "testagent", >>>> Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], >>>> Agent_ip = {xx,xxx,xxx,xxx}, >>>> Agent_port = 161 , >>>> Secure_name= Userid, >>>> >>>> Security_level = 'authPriv', >>>> Security_model = 'usm', >>>> Agent_version = 'v3', >>>> Auth_protocol = 'usmHMACSHAAuthProtocol', >>>> Priv_protocol = 'usmAesCfb128Protocol', >>>> >>>> % this is 16 in length >>>> Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), >>>> >>>> % this is 20 in length >>>> Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), >>>> >>>> ok = snmpm:register_user(Userid,snmpm_user_default,[]), >>>> >>>> ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ >>>> {auth, Auth_protocol}, >>>> {auth_key,Auth_key_local}, >>>> {priv, Priv_protocol}, >>>> {priv_key,Priv_key_local }, >>>> {sec_name, Secure_name} >>>> ]), >>>> ok = snmpm:register_agent(Userid, Agent_target ,[ >>>> {engine_id,Agent_engine_id}, >>>> {address, Agent_ip}, >>>> {port, Agent_port}, >>>> {version,Agent_version}, >>>> {sec_model,Security_model}, >>>> {sec_name,Secure_name}, >>>> {sec_level, Security_level} >>>> >>>> ]), >>>> Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), ........................ >>>> >>>> ........................ >>>> >>>> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! >>>> >>>> Thanks, Devangana >>>> >>>> _______________________________________________ >>>> 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 mjtruog@REDACTED Fri Sep 16 03:20:52 2016 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 15 Sep 2016 18:20:52 -0700 Subject: [erlang-questions] [ANN] CloudI 1.5.3 Released! Message-ID: <57DB48F4.70006@gmail.com> Download 1.5.3 from http://sourceforge.net/projects/cloudi/files/latest/download (checksums at the bottom of this email) CloudI (http://cloudi.org/) is a "universal integrator" using an Erlang core to provide fault-tolerance with efficiency and scalability. The CloudI API provides a minimal interface to communicate among services so programming language agnostic and protocol agnostic integration can occur. CloudI currently integrates with the programming languages C/C++, Elixir, Erlang, Java, JavaScript/node.js, PHP, Perl, Python, and Ruby, while including many reusable services that rely on the CloudI service bus. The details for this release are below: * services_update is a new addition to the CloudI Service API for updating any service without downtime, i.e., module hot-code reloading with internal services and OS process restarts with external services while CloudI ensures service requests are not lost and service request handlers are not interrupted in any of the service processes or threads (see http://cloudi.org/api.html#2_services_update for more information) * A Java user tutorial has been added based on the work of Bruce Kissinger (http://cloudi.org/tutorial_java.html) * The Java CloudI API can now use method references with Java 8 * New service configuration options were added or improved: 'directory', 'dispatcher_pid_options', 'init_pid_options', 'request_pid_options', 'info_pid_options' (http://cloudi.org/api.html#2_services_add has more information) * Many of the database services were removed with their dependencies, from the main repository due to service development demonstrating that failures remain isolated when using a database client locally within a service (database services can help scale usage and make sure it is fault-tolerant, but only after the service business logic is in a stable state and excluding these services will help guide developers) * cloudi_service_monitoring was improved: * Any Erlang process can create or update metrics now * cloudi.log output can be monitored with aspects_log_before or aspects_log_after * All CloudI service related metrics now have a static metric name, identified with TYPE.FILENAME.INDEX instead of the service ID as described in the ChangeLog file * Erlang internal services now have two optional behaviour functions (some services choose to use only one of the functions): * cloudi_service_handle_request/11 * cloudi_service_handle_info/3 * Bugs were fixed and other improvements were added (see the ChangeLog for more detail) Please mention any problems, issues, or ideas! Thanks, Michael SHA256 CHECKSUMS cloudi-1.5.3.tar.gz (13856 bytes) 9163adb2c12a46909daca612f71603a0bcfff4f1fc5bee78cf5178ea7bef247e cloudi-1.5.3.tar.bz2 (11352 bytes) 2e57b9b79123d482ab94b21edfa43df192122196c15179083c18fc347e12755a From erlang@REDACTED Fri Sep 16 09:16:54 2016 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 16 Sep 2016 09:16:54 +0200 Subject: [erlang-questions] every process should have a URL Message-ID: Alan Kay at 43 min and 21 seconds into his OOPSLA 1997 (the computer revolution hasn't happened) Says: "Every Object should have a URL" The video is here: https://www.youtube.com/watchv=oKg1hTOQXoY&feature=youtu.be&t=2573 The Objects that Alan talks about seem to me to be very like Erlang processes - understand polymorphic messages - have late binding etc. So how can we make truly global Pids? - global meaning an address space consisting of every machine on the planet running BEAM code. If we did this programs to do chat/email/instant messaging/.... etc would be trivial to write. What would a Pid look like - a {HostIP,PortNumber,NodeName,LocalPidinNode} tuple? Cheers /Joe From Oliver.Korpilla@REDACTED Fri Sep 16 09:38:57 2016 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Fri, 16 Sep 2016 09:38:57 +0200 Subject: [erlang-questions] every process should have a URL In-Reply-To: References: Message-ID: Hello, Joe. Couldn't this be easily spoofed? (by setting IP, hostname, nodename accordingly or man-in-the-middles etc) Also, what is the value of "local PID in node" when the basic assumption of Erlang is that a process is restarted on crash and replaced by an equivalent one? (which would have a different PID) If Erlang would replace crashed processes with processes or identical PID (and one wonders how, really) then the "local PID in node" might be interesting... else something else would seem more sensible (to me). Couldn't an Erlang node run a registry for this for every process that "wants" the overhead of having a global name? The process then could give it an ID it wants to assume just as with gproc etc. Global requests could query that registry. Spoofing problems remain, I guess, on various levels. Regards, Oliver ? Gesendet:?Freitag, 16. September 2016 um 09:16 Uhr Von:?"Joe Armstrong" An:?Erlang Betreff:?[erlang-questions] every process should have a URL Alan Kay at 43 min and 21 seconds into his OOPSLA 1997 (the computer revolution hasn't happened) Says: "Every Object should have a URL" The video is here: https://www.youtube.com/watchv=oKg1hTOQXoY&feature=youtu.be&t=2573 The Objects that Alan talks about seem to me to be very like Erlang processes - understand polymorphic messages - have late binding etc. So how can we make truly global Pids? - global meaning an address space consisting of every machine on the planet running BEAM code. If we did this programs to do chat/email/instant messaging/.... etc would be trivial to write. What would a Pid look like - a {HostIP,PortNumber,NodeName,LocalPidinNode} tuple? Cheers /Joe _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] From eric.pailleau@REDACTED Fri Sep 16 19:37:42 2016 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Fri, 16 Sep 2016 19:37:42 +0200 Subject: [erlang-questions] every process should have a URL In-Reply-To: References: Message-ID: <9g001158a6dh6jr2u5fnu8r5.1474047462388@email.android.com> Hello, Not to mention that HostIP is generally an IP like 192.168.1.21 which is used in many companies in LAN. Using a public IP per process would be necessary, hum welcome to IPv6 :)... "Envoy? depuis mon mobile " Eric ---- Oliver Korpilla a ?crit ---- >Hello, Joe. > >Couldn't this be easily spoofed? (by setting IP, hostname, nodename accordingly or man-in-the-middles etc) > >Also, what is the value of "local PID in node" when the basic assumption of Erlang is that a process is restarted on crash and replaced by an equivalent one? (which would have a different PID) > >If Erlang would replace crashed processes with processes or identical PID (and one wonders how, really) then the "local PID in node" might be interesting... else something else would seem more sensible (to me). > >Couldn't an Erlang node run a registry for this for every process that "wants" the overhead of having a global name? The process then could give it an ID it wants to assume just as with gproc etc. Global requests could query that registry. Spoofing problems remain, I guess, on various levels. > >Regards, >Oliver >? > >Gesendet:?Freitag, 16. September 2016 um 09:16 Uhr >Von:?"Joe Armstrong" >An:?Erlang >Betreff:?[erlang-questions] every process should have a URL >Alan Kay at 43 min and 21 seconds into his OOPSLA 1997 (the computer >revolution hasn't happened) > >Says: "Every Object should have a URL" > >The video is here: > >https://www.youtube.com/watchv=oKg1hTOQXoY&feature=youtu.be&t=2573 > >The Objects that Alan talks about seem to me to be very like Erlang >processes - understand polymorphic messages - have late binding etc. > >So how can we make truly global Pids? - global meaning an address space >consisting of every machine on the planet running BEAM code. > >If we did this programs to do chat/email/instant messaging/.... etc >would be trivial to write. > >What would a Pid look like - a >{HostIP,PortNumber,NodeName,LocalPidinNode} tuple? > > >Cheers > >/Joe >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions[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 ehsan.tck@REDACTED Fri Sep 16 21:13:11 2016 From: ehsan.tck@REDACTED (Ehsan Mohammadi) Date: Fri, 16 Sep 2016 19:13:11 +0000 Subject: [erlang-questions] relup with rebar3 In-Reply-To: References: Message-ID: use rebar3 -d false On Wed, Sep 14, 2016 at 12:47 PM Luis Rasc?o wrote: > Your rebar3 log says: > "Dev mode enabled, release will be symlinked" > > So probably somewhere in your rebar.config you have the dev_mode option > set, my suggestion is to try out the relup while *not* in dev mode > > On Tue, Sep 13, 2016 at 11:58 PM, Anatoly Yakovenko > wrote: > >> What do you mean? how do i switch to `dev` mode? >> >> On Tue, Sep 13, 2016 at 3:35 PM Luis Rasc?o >> wrote: >> >>> Have you tried it in not dev mode? >>> >>> On Thu, Sep 8, 2016 at 5:58 PM, Anatoly Yakovenko >> > wrote: >>> >>>> anyone familiar with this error: >>>> $ ./rebar3 relup >>>> >>>> ===> Verifying dependencies... >>>> ===> Compiling minuteman >>>> ===> Starting relx build process ... >>>> ===> Resolving OTP Applications from directories: >>>> /home/ayakovenko/Public/minuteman/_build/default/lib >>>> /home/ayakovenko/erlangs/lib >>>> ===> Resolved minuteman-0.0.2 >>>> ===> Dev mode enabled, release will be symlinked >>>> ===> Including Erts from /home/ayakovenko/erlangs >>>> ===> release successfully created! >>>> ===> Starting relx build process ... >>>> ===> Resolving OTP Applications from directories: >>>> /home/ayakovenko/Public/minuteman/_build/default/lib >>>> /home/ayakovenko/erlangs/lib >>>> /home/ayakovenko/Public/minuteman/_build/default/rel >>>> ===> Resolving available OTP Releases from directories: >>>> /home/ayakovenko/Public/minuteman/_build/default/lib >>>> /home/ayakovenko/Public/minuteman/_build/default/rel >>>> ===> could not find app kernel {2,14,4} >>>> >>>> Thanks, >>>> Anatoly >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> >>> -- >>> PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260 >>> >> > > > -- > PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw@REDACTED Sat Sep 17 20:40:54 2016 From: fw@REDACTED (Florian Weimer) Date: Sat, 17 Sep 2016 20:40:54 +0200 Subject: [erlang-questions] every process should have a URL In-Reply-To: (Joe Armstrong's message of "Fri, 16 Sep 2016 09:16:54 +0200") References: Message-ID: <87d1k2z7wp.fsf@mid.deneb.enyo.de> * Joe Armstrong: > What would a Pid look like - a > {HostIP,PortNumber,NodeName,LocalPidinNode} tuple? What if the IP address changes during the life-time of the process? What if the host has multiple addresses? I suspect just using something that can be tied to a cryptographic protocol as the identifier, plus some sort of routing protocol would probably be preferably. There are lots of such designs floating around, I think. From mfidelman@REDACTED Sun Sep 18 04:11:51 2016 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 17 Sep 2016 22:11:51 -0400 Subject: [erlang-questions] game engines? Message-ID: Hi Folks, I'm curious, has anybody written an Erlang-based game engine that implements a process per game entity? I've been been finding various examples of Erlang being used to manage user sessions, and other aspects of MMORPGs - but nothing that simply does the obvious - treating each object, player, etc. as an Erlang process. Am I missing something? Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From netch@REDACTED Sun Sep 18 11:12:21 2016 From: netch@REDACTED (Valentin Nechayev) Date: Sun, 18 Sep 2016 12:12:21 +0300 Subject: [erlang-questions] every process should have a URL In-Reply-To: References: Message-ID: <20160918091220.GB606@netch.kiev.ua> hi, Fri, Sep 16, 2016 at 09:16:54, erlang wrote about "[erlang-questions] every process should have a URL": > What would a Pid look like - a > {HostIP,PortNumber,NodeName,LocalPidinNode} tuple? Not considering routing problems, locally generated class 4 UUID instead of host IP will suffice. -netch- From max.lapshin@REDACTED Sun Sep 18 11:32:23 2016 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 18 Sep 2016 12:32:23 +0300 Subject: [erlang-questions] gen_tcp:send {error, timeout} and ways to restore situation? In-Reply-To: <77C07FC1-95C0-4C68-9F25-10BD8A6ED17C@rogvall.se> References: <77C07FC1-95C0-4C68-9F25-10BD8A6ED17C@rogvall.se> Message-ID: No, all this is not the same. When you receive error,timeout from gen_tcp:send you don't know how much data have been sent. If you do not set send_timeout, it means that there is default 3 hour timeout and your process will hang virtuall forever. Messages will flow and flow into its message queue and it will consume all your memory till OOM killer comes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sun Sep 18 12:09:50 2016 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 18 Sep 2016 12:09:50 +0200 Subject: [erlang-questions] every process should have a URL In-Reply-To: <87d1k2z7wp.fsf@mid.deneb.enyo.de> References: <87d1k2z7wp.fsf@mid.deneb.enyo.de> Message-ID: On Sat, Sep 17, 2016 at 8:40 PM, Florian Weimer wrote: > * Joe Armstrong: > >> What would a Pid look like - a >> {HostIP,PortNumber,NodeName,LocalPidinNode} tuple? > > What if the IP address changes during the life-time of the process? > What if the host has multiple addresses? > > I suspect just using something that can be tied to a cryptographic > protocol as the identifier, plus some sort of routing protocol would > probably be preferably. There are lots of such designs floating > around, I think. From erlang@REDACTED Sun Sep 18 12:23:35 2016 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 18 Sep 2016 12:23:35 +0200 Subject: [erlang-questions] every process should have a URL In-Reply-To: <87d1k2z7wp.fsf@mid.deneb.enyo.de> References: <87d1k2z7wp.fsf@mid.deneb.enyo.de> Message-ID: I guess this means the pid should just be a special form of GUID. I suppose it also means that processes become in a sense like mobile phones - mobile phones can be turned-off, connected, busy, unknown,in-transit. I guess the ideas of an operator, home location register (HLR) and visitor location (VLR) register could apply to Pids :-) Actually Telcos use HLR and VLRs and not DHTs and the results are pretty reliable. So a Pid of the form {HRLAddress, GUID} could be used The HLR either knows the host where the process with the given GUID is or it returns a VLR address and you go ask the VLR If you know what HLR and VLRs are that might make sense :-) /Joe From sgolovan@REDACTED Sun Sep 18 18:00:13 2016 From: sgolovan@REDACTED (Sergei Golovan) Date: Sun, 18 Sep 2016 19:00:13 +0300 Subject: [erlang-questions] Erlang/OTP and OpenSSL 1.1 Message-ID: Hi! Recently, new major OpenSSL version 1.1 has been released, with many API incompatibilities, and I guess sooner or later one should port Erlang crypto module to it. My first attempt of the porting can be found at https://github.com/sgolovan/otp/tree/openssl11 There are a few things that have to be changed: 1. Basically every complex type in libssl became opaque, so one can't put a variable on a stack (you can't have 'EVP_MD_CTX ctx' anymore) and can't use the struct fields directly. So, I had to add code which allocates these variables on a heap, and code which frees the resources after use. 2. Quite a few constructors and destructors were renamed to maintain names consistency (e.g. EVP_MD_CTX_new() instead of EVP_MD_CTX_create(), EVP_MD_CTX_free() instead of EVP_MD_CTX_destroy()), so I had to add quite a few #if's for old and new calls. 3. OpenSSL documentation now says that there's no need in specifying locking callbacks (actually it just doesn't say that one has to specify them and doesn't provide the way to). Old functions like CRYPTO_set_locking_callback(), CRYPTO_set_id_callback() became macros which expand to nothing. So, I've added a preprocessor guards to switch them off for 1.1. 4. New libssl implements chacha20-poly1305 cipher (there's no need in patching anymore), so I've reimplemented the encryption/decryption with this cipher using the libssl uniform interface. The problem with it is that it implements RFC 7539 (https://tools.ietf.org/html/rfc7539) which differs to the current implementation (a draft from https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 ) in two ways: first, the nonce size is changed from 8 to 12 bytes (8 bytes is still acceptable, it shifts left by 32 bits), which isn't too bad because the discrepancies can be found only after 32-bit block counter overflows (which isn't very plausible). Second, the tag calculation algorithm has been changed (see https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#page-8 vs https://tools.ietf.org/html/rfc7539#page-19 ). This means that the implementations aren't compatible. As for now I've added two test cases for the new implementation (and haven't removed the old case, so the test fails at the moment). I'd say that the old implementation should be dropped some time. Okay then. I hope this porting attempt will be helpful. Cheers! -- Sergei Golovan From unix1@REDACTED Sun Sep 18 18:14:28 2016 From: unix1@REDACTED (Unix One) Date: Sun, 18 Sep 2016 16:14:28 +0000 Subject: [erlang-questions] game engines? In-Reply-To: References: Message-ID: On 09/17/2016 07:11 PM, Miles Fidelman wrote: > Hi Folks, > > I'm curious, has anybody written an Erlang-based game engine that > implements a process per game entity? > > I've been been finding various examples of Erlang being used to manage > user sessions, and other aspects of MMORPGs - but nothing that simply > does the obvious - treating each object, player, etc. as an Erlang process. I wrote a very bare bones generic turn based game server https://github.com/unix1/nuk where every instance of a game, and every active player is an Erlang process. It doesn't have a concept/storage for objects in the game (did I mention it's very bare bones?), but it seems like not too complex to add based on use cases. On a side note, I don't have much game-writing experience, but it seems like they might benefit greatly from their own DSLs, in which case I thought LFE is probably better suited for the task. Finally, please do share what you mean and/or links re: "other aspects of MMORPGs". I'm interested. Thank you. From lloyd@REDACTED Sun Sep 18 18:56:22 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Sun, 18 Sep 2016 12:56:22 -0400 (EDT) Subject: [erlang-questions] List comprehension puzzler Message-ID: <1474217782.958230279@apps.rackspace.com> Hello, Now this I would not expect: 4> S = "123a456". "123a456" 5> is_integer(S). false 6> [is_integer(I) || I <- S]. [true,true,true,true,true,true,true] Please tell me what I don't understand. Many thanks, LRP ********************************************* My books: THE GOSPEL OF ASHES http://thegospelofashes.com Strength is not enough. Do they have the courage and the cunning? Can they survive long enough to save the lives of millions? FREEIN' PANCHO http://freeinpancho.com A community of misfits help a troubled boy find his way AYA TAKEO http://ayatakeo.com Star-crossed love, war and power in an alternative universe Available through Amazon or by request from your favorite bookstore ********************************************** From dangud@REDACTED Sun Sep 18 19:03:24 2016 From: dangud@REDACTED (Dan Gudmundsson) Date: Sun, 18 Sep 2016 17:03:24 +0000 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <1474217782.958230279@apps.rackspace.com> References: <1474217782.958230279@apps.rackspace.com> Message-ID: What happens when you write it out? io:format("~w~n",[S]). [49,50,51,97,52,53,54] Hmm a strange list of integers appears. A string in erlang is a (normal) list of characters/unicode codepoints which are represented by their integer value. On Sun, Sep 18, 2016 at 6:56 PM wrote: > Hello, > > Now this I would not expect: > > 4> S = "123a456". > "123a456" > > 5> is_integer(S). > false > > 6> [is_integer(I) || I <- S]. > [true,true,true,true,true,true,true] > > Please tell me what I don't understand. > > Many thanks, > > LRP > > > ********************************************* > My books: > > THE GOSPEL OF ASHES > http://thegospelofashes.com > > Strength is not enough. Do they have the courage > and the cunning? Can they survive long enough to > save the lives of millions? > > FREEIN' PANCHO > http://freeinpancho.com > > A community of misfits help a troubled boy find his way > > AYA TAKEO > http://ayatakeo.com > > Star-crossed love, war and power in an alternative > universe > > Available through Amazon or by request from your > favorite bookstore > > > ********************************************** > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sun Sep 18 19:27:49 2016 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sun, 18 Sep 2016 17:27:49 +0000 Subject: [erlang-questions] every process should have a URL In-Reply-To: References: <87d1k2z7wp.fsf@mid.deneb.enyo.de> Message-ID: On Sun, Sep 18, 2016 at 12:23 PM Joe Armstrong wrote: > I guess this means the pid should just be a special form of GUID. I suppose > it also means that processes become in a sense like mobile phones - > mobile phones can be turned-off, connected, busy, unknown,in-transit. > > I guess the ideas of an operator, home location register (HLR) and > visitor location (VLR) register could apply to Pids :-) > > Actually Telcos use HLR and VLRs and not DHTs and the results > are pretty reliable. > > So a Pid of the form {HRLAddress, GUID} could be used > > The HLR either knows the host where the process with the given GUID is > or it returns a VLR address and you go ask the VLR > > If you know what HLR and VLRs are that might make sense :-) > > /Joe > > Using a system like HLR/VLR sounds appropriate there. How would you call the host, or rather their resolution ? node@REDACTED ? - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sun Sep 18 19:30:33 2016 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sun, 18 Sep 2016 17:30:33 +0000 Subject: [erlang-questions] reorder SSL certificate chain with Erlang 19 In-Reply-To: References: Message-ID: Thanks for the patch! I will try tomorrow and let you know :) - benoit On Thu, Sep 15, 2016 at 10:28 AM Ingela Andin wrote: > Hi! > > Please try this branch > > > *IngelaAndin:ingela/ssl/unorded-cert-chain/OTP-12983 > > * > > It does not break existing code. But it is not prioritized to Ericsson, so > I do not have the time to make a real test case at the moment. That would > require me to either to craft a way to send it out of order or use some > other implementation that does this.) > > Regards Ingela Erlang/OTP Team - Ericsson AB > > > 2016-09-12 12:23 GMT+02:00 Benoit Chesneau : > >> Is there anyway now to reorder the certificate chain received with >> Erlang 19 like browsers and most languages do by default. Maybe in an >> hackish way? >> >> It's actually the cause of many connection issue via http to some servers >> and the response can't just be about asking the server owner to fix it. >> Users expect that the connection will work as it is with curl. >> >> Any hint is appreciated :) >> >> - benoit >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.behnke@REDACTED Sun Sep 18 19:37:22 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Sun, 18 Sep 2016 19:37:22 +0200 Subject: [erlang-questions] game engines? In-Reply-To: References: Message-ID: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> Hello, assigning each object in the game gets difficult for a number of reasons, when trying to do this for an MMO, especially MMORPGs (characterized by a very large number of objects, and active entities): You waste resources (CPU, RAM) when an object is currently not being referenced by an active entity (e.g. a client connection, thus and avatar or alternatively a Mob/NPC), since there is no other process that will send any messages. More importantly, should you scale your engine to multiple hosts, you either have to enforce a single process, requiring all updates and query messages to be routed to this proc. Or you will have to build some master/slave or peer to peer logic, which will ensure consistency in the face of CAP. Separating into a) the state of instances, which you can store in a KV-store and have b) a pool of generic procs, that will process the state with c) a set of modules that provides the logic for a particular object allows to push the state to the appropriate host. With a separate KV-store that can handle net-partition and node failure, you gain even a good amount of fault-resilience. Please excuse me beating my own drum, but I have implemented a prototype of such an engine (http://dl.acm.org/citation.cfm?id=2577389&CFID=787355984&CFTOKEN=91169762). Unfortunately, for legal reason, I cannot make the code publicly available yet. mfg lutz Am 18.09.2016 um 04:11 schrieb Miles Fidelman: > Hi Folks, > > I'm curious, has anybody written an Erlang-based game engine that > implements a process per game entity? > > I've been been finding various examples of Erlang being used to manage > user sessions, and other aspects of MMORPGs - but nothing that simply > does the obvious - treating each object, player, etc. as an Erlang process. > > Am I missing something? > > Thanks, > > Miles Fidelman > > -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5006 bytes Desc: S/MIME Cryptographic Signature URL: From mjtruog@REDACTED Sun Sep 18 21:34:08 2016 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 18 Sep 2016 12:34:08 -0700 Subject: [erlang-questions] game engines? In-Reply-To: References: Message-ID: <57DEEC30.7070904@gmail.com> On 09/17/2016 07:11 PM, Miles Fidelman wrote: > Hi Folks, > > I'm curious, has anybody written an Erlang-based game engine that implements a process per game entity? > > I've been been finding various examples of Erlang being used to manage user sessions, and other aspects of MMORPGs - but nothing that simply does the obvious - treating each object, player, etc. as an Erlang process. http://www.naos-engine.com/ uses Erlang to manage NPCs and if the Actor Model concept is used in gaming, it is normally to manage at least the NPCs. With typical Erlang usage you will have an Erlang process per PC socket connection. So, treating each NPC and PC as an Erlang process should be a natural approach. Best Regards, Michael From ok@REDACTED Mon Sep 19 02:51:46 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 19 Sep 2016 12:51:46 +1200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <1474217782.958230279@apps.rackspace.com> References: <1474217782.958230279@apps.rackspace.com> Message-ID: <4347a720-47cb-6a3a-a750-240025b08915@cs.otago.ac.nz> On 19/09/16 4:56 AM, lloyd@REDACTED wrote: > 4> S = "123a456". > "123a456" The documentation is very clear: Erlang reference manual section 3.12 Strings http://erlang.org/doc/reference_manual/data_types.html#id71049 Strings are enclosed in double quotes ("), but is(sic.) not a data type in Erlang. Instead, a string "hello" is shorthand for the list [$h,$e,$l,$l,$o], that is, [104,101,108,108,111]. When the shell sees a list that might have been a string, it prints it as a string. So > [65,66,67]. "ABC" You entered a list of integers using string syntax. The shell printed that list of integers using string syntax. > 5> is_integer(S). > false Why would you ever have thought that S *might* be an integer? If you want a hexadecimal integer, section 3.2 is clear. 16#123a456 is an integer in hex. > > 6> [is_integer(I) || I <- S]. > [true,true,true,true,true,true,true] So you did know that S is a list. > > Please tell me what I don't understand. That would require us to read your mind. What did you expect to happen and why did you expect that? Here's Prolog: ?- S = "123a456". S = [49, 50, 51, 97, 52, 53, 54] Yes ?- S = "123a456", member(X, S), \+ integer(X). No Here's Haskell: Prelude> :type "123a456" "123a456" :: [Char] (That is, "123a456" is a list of characters. Char and Int are distinct in Haskell, not in Erlang or Prolog.) From john.ashmun@REDACTED Mon Sep 19 03:34:54 2016 From: john.ashmun@REDACTED (John R. Ashmun) Date: Sun, 18 Sep 2016 18:34:54 -0700 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <4347a720-47cb-6a3a-a750-240025b08915@cs.otago.ac.nz> References: <1474217782.958230279@apps.rackspace.com> <4347a720-47cb-6a3a-a750-240025b08915@cs.otago.ac.nz> Message-ID: What, no APL? Kudos, master, for your restraint on the all-caps front. I sincerely appreciate that. On Sun, Sep 18, 2016 at 5:51 PM, Richard A. O'Keefe wrote: > > > On 19/09/16 4:56 AM, lloyd@REDACTED wrote: > >> 4> S = "123a456". >> "123a456" >> > > The documentation is very clear: > > Erlang reference manual section 3.12 Strings > http://erlang.org/doc/reference_manual/data_types.html#id71049 > > Strings are enclosed in double quotes ("), > but is(sic.) not a data type in Erlang. > Instead, a string "hello" is shorthand for the list > [$h,$e,$l,$l,$o], that is, [104,101,108,108,111]. > > When the shell sees a list that might have been a string, > it prints it as a string. So > > > [65,66,67]. > "ABC" > > You entered a list of integers using string syntax. > The shell printed that list of integers using string syntax. > > 5> is_integer(S). >> false >> > > Why would you ever have thought that S *might* be an integer? > If you want a hexadecimal integer, section 3.2 is clear. > > 16#123a456 > > is an integer in hex. > >> >> 6> [is_integer(I) || I <- S]. >> [true,true,true,true,true,true,true] >> > > So you did know that S is a list. > >> >> Please tell me what I don't understand. >> > > That would require us to read your mind. What did you expect > to happen and why did you expect that? > > Here's Prolog: > > ?- S = "123a456". > > S = [49, 50, 51, 97, 52, 53, 54] > > Yes > ?- S = "123a456", member(X, S), \+ integer(X). > > No > > Here's Haskell: > Prelude> :type "123a456" > "123a456" :: [Char] > > (That is, "123a456" is a list of characters. Char and Int are > distinct in Haskell, not in Erlang or Prolog.) > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Sep 19 04:29:30 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 19 Sep 2016 14:29:30 +1200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <4347a720-47cb-6a3a-a750-240025b08915@cs.otago.ac.nz> Message-ID: On 19/09/16 1:34 PM, John R. Ashmun wrote: > What, no APL? You want APL? I didn't think it would help, because while characters are integers in APL, strings are not lists, they're arrays. However, I suppose I could mention that ?/('BCD'=1+'ABC') is true in APL. From ok@REDACTED Mon Sep 19 07:05:52 2016 From: ok@REDACTED (ok@REDACTED) Date: Mon, 19 Sep 2016 17:05:52 +1200 Subject: [erlang-questions] Apology Message-ID: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> I have been taken to task in private e-mail by someone who detected in my response to the "list comprehension puzzle" both "aggressive sarcasm" and "undisguised contempt". In all honesty, no sarcasm was intended. (A sarcastic response would not have pointed to the Erlang reference manual.) Nor was any contempt whatsoever involved. I should not have to reassure long-term readers of this mailing list that these attitudes my critic claimed to detect were entirely imaginary. However, it shows that it was possible for people to misread what I wrote. If anyone took offence at the message I *meant* to be helpful, please accept my assurance that no offence was intended and my unreserved apology for the offence. From essen@REDACTED Mon Sep 19 09:07:30 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 19 Sep 2016 09:07:30 +0200 Subject: [erlang-questions] Apology In-Reply-To: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> Message-ID: <46dfd6ae-fe2e-30d4-77e2-09f733390638@ninenines.eu> There was obviously no ill intent in that message. But intent is hard to convey through text and people read posts with their own bias, which leads to such imaginary interpretations. Nowadays an increasingly large amount of people is looking to get offended; that's their own bias, and anything ambiguous will be taken as offense. It's a shame as it makes civil discussion and good intents much more difficult to pull off; discouraging. Anyway I'm probably not the only one who thinks you're doing a fantastic job answering the many questions that are posted on this list, in great details, regardless of how trivial they are or how confused the poster is. Instead of you apologising, it should instead be everyone else thanking you for this. So let me start. Thanks! On 09/19/2016 07:05 AM, ok@REDACTED wrote: > I have been taken to task in private e-mail by someone > who detected in my response to the "list comprehension puzzle" > both "aggressive sarcasm" and "undisguised contempt". > > In all honesty, no sarcasm was intended. (A sarcastic response > would not have pointed to the Erlang reference manual.) Nor > was any contempt whatsoever involved. I should not have to > reassure long-term readers of this mailing list that these > attitudes my critic claimed to detect were entirely imaginary. > > However, it shows that it was possible for people to misread > what I wrote. If anyone took offence at the message I > *meant* to be helpful, please accept my assurance that no > offence was intended and my unreserved apology for the offence. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From michael.nisi@REDACTED Mon Sep 19 09:39:42 2016 From: michael.nisi@REDACTED (Michael Nisi) Date: Mon, 19 Sep 2016 09:39:42 +0200 Subject: [erlang-questions] Apology In-Reply-To: <46dfd6ae-fe2e-30d4-77e2-09f733390638@ninenines.eu> References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> <46dfd6ae-fe2e-30d4-77e2-09f733390638@ninenines.eu> Message-ID: I couldn't agree more. Your posts are an invaluable resource of knowledge and delight, which I always gratefully receive. Thank you! On Mon, Sep 19, 2016 at 9:07 AM, Lo?c Hoguin wrote: > There was obviously no ill intent in that message. But intent is hard to > convey through text and people read posts with their own bias, which leads > to such imaginary interpretations. Nowadays an increasingly large amount of > people is looking to get offended; that's their own bias, and anything > ambiguous will be taken as offense. It's a shame as it makes civil > discussion and good intents much more difficult to pull off; discouraging. > > Anyway I'm probably not the only one who thinks you're doing a fantastic > job answering the many questions that are posted on this list, in great > details, regardless of how trivial they are or how confused the poster is. > > Instead of you apologising, it should instead be everyone else thanking > you for this. So let me start. Thanks! > > > On 09/19/2016 07:05 AM, ok@REDACTED wrote: > >> I have been taken to task in private e-mail by someone >> who detected in my response to the "list comprehension puzzle" >> both "aggressive sarcasm" and "undisguised contempt". >> >> In all honesty, no sarcasm was intended. (A sarcastic response >> would not have pointed to the Erlang reference manual.) Nor >> was any contempt whatsoever involved. I should not have to >> reassure long-term readers of this mailing list that these >> attitudes my critic claimed to detect were entirely imaginary. >> >> However, it shows that it was possible for people to misread >> what I wrote. If anyone took offence at the message I >> *meant* to be helpful, please accept my assurance that no >> offence was intended and my unreserved apology for the offence. >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Mon Sep 19 10:56:24 2016 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Mon, 19 Sep 2016 11:56:24 +0300 Subject: [erlang-questions] Stopping a process with its supervision subtree In-Reply-To: <92DCBCE1-B759-4E50-86FA-DC7488632A52@gmail.com> References: <92DCBCE1-B759-4E50-86FA-DC7488632A52@gmail.com> Message-ID: Hello, On Wed, Sep 14, 2016 at 8:20 PM, Dmitry Kolesnikov wrote: > Hello, > > This is a good question! I?d like to get other's opinion on the subject as well. > I would go with following pattern: > > * S_X is {one_for_all, 0, 1} and all its child are permanent. > * The process P_2 just {stop, normal, State} when the job is done. > > I do not like to ?leak? a knowledge of supervisor to child processes. I?ll try to avoid usage of supervisor:terminate_child(?). On another hand, this pattern has disadvantage. You?ll see a ?supervisor? S_X crash in the log when P_2 stops due to ?permanent? property. > > The usage of simple_one_to_one supervisor seems to be right for this type of use-cases but it misses concept of related processes. > > What do you think? > Your note on the knowledge leak to the child process is right. Sometimes I make child processes to know, how to start themselves within its supervisor, e.g. -module(p). start_sup(X) -> p_sup:start_child(X). start_link(X) -> gen_server:start_link(...). In this case, the process knows the supervisor anyway, so addition of the call for stopping the process is not making things worse (at least with knowledge leaking). Although I am not sure, if the process module should have knowledge on the supervision tree, or it is better to leave that knowledge to the caller/client process. Your approach is interesting. I haven't considered it. I'm not sure, if it would allow to differentiate between crashes of P_X (exits with reason /= normal) and the normal termination. The same is for differentiation between the main process (P_X) and its helper processes). The false crash reports would make log analysis more complicated: it would be not enough to find [error] to consider it error. Admins wouldn't be happy about that. > > Best Regards, > Dmitry > > Karolis From roger@REDACTED Mon Sep 19 11:00:30 2016 From: roger@REDACTED (Roger Price) Date: Mon, 19 Sep 2016 11:00:30 +0200 (CEST) Subject: [erlang-questions] Apology In-Reply-To: <46dfd6ae-fe2e-30d4-77e2-09f733390638@ninenines.eu> References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> <46dfd6ae-fe2e-30d4-77e2-09f733390638@ninenines.eu> Message-ID: On Mon, 19 Sep 2016, Lo?c Hoguin wrote: > There was obviously no ill intent in that message. ... > > Anyway I'm probably not the only one who thinks you're doing a fantastic > job answering the many questions that are posted on this list, in great > details, regardless of how trivial they are or how confused the poster is. > > On 09/19/2016 07:05 AM, ok@REDACTED wrote: >> I have been taken to task in private e-mail by someone >> who detected in my response to the "list comprehension puzzle" >> both "aggressive sarcasm" and "undisguised contempt". When citing the Erlang reference manual section 3.12 is seen as "aggressive sarcasm" and "undisguised contempt" then this must be the snowflake generation. Perhaps section 3.12 needs a trigger warning :-) A loud and enthusiastic "Thankyou" to ROK for many excellent postings. I keep a stash of some which I think are outstanding. Roger From freza@REDACTED Mon Sep 19 11:14:26 2016 From: freza@REDACTED (Jachym Holecek) Date: Mon, 19 Sep 2016 05:14:26 -0400 Subject: [erlang-questions] Stopping a process with its supervision subtree In-Reply-To: <92DCBCE1-B759-4E50-86FA-DC7488632A52@gmail.com> References: <92DCBCE1-B759-4E50-86FA-DC7488632A52@gmail.com> Message-ID: <20160919091426.GA22246@circlewave.net> Hi, # Dmitry Kolesnikov 2016-09-14: > This is a good question! I?d like to get other's opinion on the subject as well. > I would go with following pattern: > > * S_X is {one_for_all, 0, 1} and all its child are permanent. > * The process P_2 just {stop, normal, State} when the job is done. > > I do not like to ?leak? a knowledge of supervisor to child processes. I?ll try to > avoid usage of supervisor:terminate_child(?). On another hand, this pattern has > disadvantage. You?ll see a ?supervisor? S_X crash in the log when P_2 stops due to > ?permanent? property. Not knowing the full use case at hand I'll say that supervisors are generally used to manage the long-lived part of process hierarchy. It is a perfectly reasonable and common pattern to have a process manage its own children without supervisors, using just links and/or trap_exit and/or monitors. So when your "management" pro- cess terminates its auxiliary processes are shut down as well. That's why these primitives are built into the language after all. Feel free to elaborate more precisely on what you're trying to do and why, in case the above doesn't seem helpful. > The usage of simple_one_to_one supervisor seems to be right for this type of > use-cases but it misses concept of related processes. I think simple_one_to_one supervisors are something of a historical mistake, their behaviour differes noticeably from the normal supervision strategies (enough so to come across as an inconsistency) and the functionality they offer is ridiculously easy to implement oneself in a way that exactly matches the use case at hand, not complicating things with unnecessary abstractions. BR, -- Jachym From aschultz@REDACTED Mon Sep 19 11:22:35 2016 From: aschultz@REDACTED (Andreas Schultz) Date: Mon, 19 Sep 2016 11:22:35 +0200 (CEST) Subject: [erlang-questions] Erlang/OTP and OpenSSL 1.1 In-Reply-To: References: Message-ID: <218962421.191087.1474276955274.JavaMail.zimbra@tpip.net> Hi Sergei, ----- Original Message ----- > From: "Sergei Golovan" > To: "erlang-questions" > Sent: Sunday, September 18, 2016 6:00:13 PM > Subject: [erlang-questions] Erlang/OTP and OpenSSL 1.1 > Hi! > > Recently, new major OpenSSL version 1.1 has been released, with many > API incompatibilities, and I guess sooner or later one should port > Erlang crypto module to it. My first attempt of the porting can be > found at https://github.com/sgolovan/otp/tree/openssl11 > > There are a few things that have to be changed: > > 1. Basically every complex type in libssl became opaque, so one can't > put a variable on a stack (you can't have 'EVP_MD_CTX ctx' anymore) > and can't use the struct fields directly. So, I had to add code which > allocates these variables on a heap, and code which frees the > resources after use. > > 2. Quite a few constructors and destructors were renamed to maintain > names consistency (e.g. EVP_MD_CTX_new() instead of > EVP_MD_CTX_create(), EVP_MD_CTX_free() instead of > EVP_MD_CTX_destroy()), so I had to add quite a few #if's for old and > new calls. > > 3. OpenSSL documentation now says that there's no need in specifying > locking callbacks (actually it just doesn't say that one has to > specify them and doesn't provide the way to). Old functions like > CRYPTO_set_locking_callback(), CRYPTO_set_id_callback() became macros > which expand to nothing. So, I've added a preprocessor guards to > switch them off for 1.1. > > 4. New libssl implements chacha20-poly1305 cipher (there's no need in > patching anymore), so I've reimplemented the encryption/decryption > with this cipher using the libssl uniform interface. The problem with > it is that it implements RFC 7539 > (https://tools.ietf.org/html/rfc7539) which differs to the current > implementation (a draft from > https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 ) in two > ways: first, the nonce size is changed from 8 to 12 bytes (8 bytes is > still acceptable, it shifts left by 32 bits), which isn't too bad > because the discrepancies can be found only after 32-bit block counter > overflows (which isn't very plausible). Second, the tag calculation > algorithm has been changed (see > https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#page-8 > vs https://tools.ietf.org/html/rfc7539#page-19 ). This means that the > implementations aren't compatible. As for now I've added two test > cases for the new implementation (and haven't removed the old case, so > the test fails at the moment). I'd say that the old implementation > should be dropped some time. At least for SSL, that shouldn't be a problem. Currently SSL uses a cipher id for the ChaCha20 cipher that indicates to old version. The final RFC for ChaCha in TLS did define different cipher ids. So, the SSL module should be adjusted at the time to the new version. Andreas > > Okay then. I hope this porting attempt will be helpful. > > Cheers! > -- > Sergei Golovan > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mfidelman@REDACTED Mon Sep 19 14:38:41 2016 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 19 Sep 2016 08:38:41 -0400 Subject: [erlang-questions] Apology In-Reply-To: References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> <46dfd6ae-fe2e-30d4-77e2-09f733390638@ninenines.eu> Message-ID: <46e71c67-8769-81cd-467d-565c7fcdb9e9@meetinghouse.net> On 9/19/16 5:00 AM, Roger Price wrote: > On Mon, 19 Sep 2016, Lo?c Hoguin wrote: > >> There was obviously no ill intent in that message. ... >> >> Anyway I'm probably not the only one who thinks you're doing a >> fantastic job answering the many questions that are posted on this >> list, in great details, regardless of how trivial they are or how >> confused the poster is. >> >> On 09/19/2016 07:05 AM, ok@REDACTED wrote: >>> I have been taken to task in private e-mail by someone >>> who detected in my response to the "list comprehension puzzle" >>> both "aggressive sarcasm" and "undisguised contempt". > > When citing the Erlang reference manual section 3.12 is seen as > "aggressive sarcasm" and "undisguised contempt" then this must be the > snowflake generation. Perhaps section 3.12 needs a trigger warning :-) > > A loud and enthusiastic "Thankyou" to ROK for many excellent postings. > I keep a stash of some which I think are outstanding. > Likewise! Miles Fidelman p.s. Personally, I'm a big fan of "aggressive sarcasm" - sometimes it's more than appropriate. :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From devangana@REDACTED Mon Sep 19 15:46:28 2016 From: devangana@REDACTED (Devangana Tarafdar) Date: Mon, 19 Sep 2016 08:46:28 -0500 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> Message-ID: Sorry about the late reply Daniel, I missed the email. Yes the engine id was correct in the wireshark trace. That was the first thing I had to correct. I had to convert the engine id string to an explicit list of decimals for the id. On Sep 15, 2016 10:52 AM, "Daniel Goertzen" wrote: > Check that the engine ids are what you expect them to be. You've redacted > all the engine ids from the trace, so I can't check them. > > The SNMP config files have trouble storing non-ascii engine ids; not sure > if this affect you. This should be fixed agent-side for 19.1, not sure > about manager-side. > > On Wed, Sep 14, 2016 at 1:42 PM Devangana Tarafdar > wrote: > >> Hi Dominik, >> >> So I was able look at the wireshark stream decoded after entering snmp >> credentials (that was very helpful, thanks !) and compared the 2 streams : >> One from the snmp get tool and the other from the erlang script. >> >> Wireshark is not able to decode the encrypted pdu in the erlang stream >> but it can decode the snmpget stream. >> >> The message is clear enough I suppose but I don't know what I am doing >> wrong with the key. >> >> I changed my local key generation to : >> >> %Priv_key_local = snmp:passwd2localized_key(sha, Priv_key , >> Agent_engine_id), >> >> % since auth protocol is SHA >> Priv_key_local = lists:sublist(snmp:passwd2localized_key(sha, Priv_key >> , Agent_engine_id),16), >> >> but it did not help. >> >> >> msgData: encryptedPDU (1) >> encryptedPDU: 8a3e7fc633c531d2747782a6fc8d89187c452929426e4b6e... >> Decrypted data not formatted as expected, wrong key? >> [Expert Info (Warn/Malformed): Decrypted data not >> formatted as expected] >> [Message: Decrypted data not formatted as expected] >> [Severity level: Warn] >> [Group: Malformed] >> >> >> Attaching good wireshark trace from snmpget and a bad one from erlang. >> >> Also tried putting a context name but did not work but snmpget does not >> put one and it works. >> >> Thanks, >> Devangana >> >> >> >> On Sun, Sep 11, 2016 at 4:09 PM, Devangana Tarafdar >> wrote: >> >>> Hi Dominik, >>> >>> I have not looked into the context. Will check all the items that you >>> mention. I have been able to connect to the agent using snmpwalk and >>> snmpget though I have not studied the wireshark output of those in detail. >>> Thanks again for all these tips and I will get back to you . >>> >>> Devangana >>> >>> On Sep 11, 2016 3:08 PM, "Dominik Pawlak" >>> wrote: >>> >>>> Hello Devangana, >>>> Hard to tell, but I see that you haven't specified any context in your >>>> sync_get. Are you sure it is not needed? I would also double check the >>>> engine id and security configuration. >>>> Have you managed to connect to that agent from something other than OTP >>>> (say snmpb, snmpget)? >>>> If so, you can compare in Wireshark, the snmp requests from erlang and >>>> from that tool. You can even enter your snmp credentials in Wireshark and >>>> it will decode encrypted messages. >>>> I hope any of this helps. >>>> >>>> Best >>>> Dominik >>>> >>>> On 11.09.2016 16:46, Devangana Tarafdar wrote: >>>> >>>> Hello Dominik, >>>> >>>> Thanks you for the reply. >>>> >>>> I sent another sync_get after the first as you suggested. The >>>> wireshark trace shows the manager has updated the 'msgAuthoritativeEngineBoots' >>>> and 'msgAuthoritativeEngineTime' to the values sent by the Agent as you >>>> pointed out. But now the agent does not respond at all and the sync_get >>>> fails with a timeout. I tried adding a second's sleep between the 2 gets as >>>> well. I don't have access currently to the agent's logs or configuration >>>> but have you seen this before ? >>>> >>>> Thanks ! >>>> Devangana >>>> >>>> >>>> On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak < >>>> dominik_pawlak@REDACTED> wrote: >>>> >>>>> Hello Devangana, >>>>> Basically, you just have to perform the sync_get once more. I observed >>>>> similar behavior in OTP 17.1 (snmp 4.25.1). The first request will always >>>>> fail because the manager is not fully configured to communicate with the >>>>> agent (more on that below). >>>>> >>>>> A longer explanation: >>>>> >>>>> In snmp v3 there is a process called 'discovery', which should be >>>>> performed before secure communication with the agent can be established. It >>>>> is described here: >>>>> >>>>> https://tools.ietf.org/html/rfc3414#section-4 >>>>> >>>>> The snmp library in OTP does not implement that process (at least not >>>>> as described in the RFC). >>>>> This process has two steps: 'snmpEngineID discovery' and 'time >>>>> synchronization'. >>>>> The first step is skipped altogether in OTP - you have to provide >>>>> engine id upfront. >>>>> The second step is performed by the first request - it will always >>>>> fail with the 'usmStatsNotInTimeWindows' error report message, but it will >>>>> set the required 'msgAuthoritativeEngineBoots' and >>>>> 'msgAuthoritativeEngineTime' in the manager. >>>>> >>>>> Best, >>>>> Dominik >>>>> >>>>> >>>>> On 10.09.2016 06:48, Devangana Tarafdar wrote: >>>>> >>>>> Hello, >>>>> >>>>> I am trying to connect to a third party SNMP agent, using snmp manager >>>>> (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running into a >>>>> problem where the agent is returning this error on the manager calling >>>>> sync_get: >>>>> >>>>> >>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>>> handle_snmp_report -> entry with >>>>> Domain: snmpUDPDomain >>>>> Addr: {{xx,xxx,xxx,xxx},161} >>>>> ReqId: 37078226 >>>>> Rep: {invalid_sec_info,[{sec_level,3,1}, >>>>> {request_id,37078226,2147483647}]} >>>>> Pdu: {pdu,report,2147483647,noError,0, >>>>> [{varbind,[1,3,6,1,6,3,15,1, >>>>> 1,2,0],'Counter32',33,1}]} >>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** >>>>> handle_snmp_report -> found corresponding request: >>>>> reply to sync request >>>>> Ref: #Ref<0.0.4.210> >>>>> ModRef: #Ref<0.0.4.211> >>>>> From: {<0.3.0>,#Ref<0.0.4.202>} >>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>>> handle_snmp_pdu(get-response) -> Remaining: 4979 >>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>>> handle_snmp_report -> deliver reply >>>>> >>>>> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226, >>>>> 2147483647}],{noError,0,[{varbind,[1,3,6,1, >>>>> 6,3,15,1,1,2,0],'Counter32',33,1}]}}} >>>>> >>>>> *** [2016:09:08 21:26:00 831] >>>>> >>>>> Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" >>>>> (from http://www.oid-info.com/) >>>>> >>>>> I have attached a wireshark trace for the snmp part of this exchange. >>>>> >>>>> I am invoking the snmpm module functions through a basic script as >>>>> follows (using tips from the tutorial at >>>>> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) >>>>> ......... >>>>> .......... >>>>> >>>>> ok = application:start(crypto), >>>>> ok = application:start(snmp), >>>>> >>>>> Userid = "snmp3user", >>>>> Agent_target = "testagent", >>>>> Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], >>>>> Agent_ip = {xx,xxx,xxx,xxx}, >>>>> Agent_port = 161 , >>>>> Secure_name= Userid, >>>>> >>>>> Security_level = 'authPriv', >>>>> Security_model = 'usm', >>>>> Agent_version = 'v3', >>>>> Auth_protocol = 'usmHMACSHAAuthProtocol', >>>>> Priv_protocol = 'usmAesCfb128Protocol', >>>>> >>>>> % this is 16 in length >>>>> Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), >>>>> >>>>> % this is 20 in length >>>>> Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), >>>>> >>>>> ok = snmpm:register_user(Userid,snmpm_user_default,[]), >>>>> >>>>> ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ >>>>> {auth, Auth_protocol}, >>>>> {auth_key,Auth_key_local}, >>>>> {priv, Priv_protocol}, >>>>> {priv_key,Priv_key_local }, >>>>> {sec_name, Secure_name} >>>>> ]), >>>>> ok = snmpm:register_agent(Userid, Agent_target ,[ >>>>> {engine_id,Agent_engine_id}, >>>>> {address, Agent_ip}, >>>>> {port, Agent_port}, >>>>> {version,Agent_version}, >>>>> {sec_model,Security_model}, >>>>> {sec_name,Secure_name}, >>>>> {sec_level, Security_level} >>>>> >>>>> ]), >>>>> Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), ........................ >>>>> >>>>> ........................ >>>>> >>>>> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! >>>>> >>>>> Thanks, Devangana >>>>> >>>>> _______________________________________________ >>>>> 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 shaobo.ye@REDACTED Mon Sep 19 16:57:19 2016 From: shaobo.ye@REDACTED (=?utf-8?B?5Y+25bCR5rOi?=) Date: Mon, 19 Sep 2016 22:57:19 +0800 Subject: [erlang-questions] question about binary memory In-Reply-To: References: Message-ID: Hi, My question is about the binary memory usage. I implemented a server which accepts Tcp connection. All the Tcp connections use binary options. Before I set up 10000 Tcp connections to my server, the memory usage is as below: (node1@REDACTED)1> erlang:memory(). [{total,100311433}, {processes,24898112}, {processes_used,24895144}, {system,75413321}, {atom,1517705}, {atom_used,1506108}, {binary,3115928}, {code,48956174}, {ets,3556416}, {maximum,102757346}] after I set up 10000 Tcp connections, every connection is hold by one gen_server; the memory usage is as below: (node1@REDACTED)5>erlang:memory(). [{total,2616776425}, {processes,92150752}, {processes_used,92138976}, {system,2524625673}, {atom,1517705}, {atom_used,1506108}, {binary,2437117184}, {code,48956174}, {ets,13264464}, {maximum,2848153566}] And I check the binary hold by all the processes on the node with the command below: List = [begin {binary, L} = erlang:process_info(P, binary), {P, (lists:foldl(fun({_, I, _}, Acc) -> Acc + I end, 0, L))} end || P <- processes() -- [self()]], lists:foldl(fun({_, A}, Acc) -> A + Acc end, 0, List). the result is 23113860. It is much less than the value 2437117184 reported by erlang:memory(). My question is : why does the VM allocate so much memory for binary? Does the Tcp ports allocate their send/recv buffer on binary heap? Is there any way I can see what are in the binary heap? Thanks, BRs/Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmytro.lytovchenko@REDACTED Mon Sep 19 17:44:03 2016 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Mon, 19 Sep 2016 15:44:03 +0000 Subject: [erlang-questions] question about binary memory In-Reply-To: References: Message-ID: Binary memory stores all binary data larger than 64 bytes. Every process that had such a binary holds a reference-counted pointer to this memory. When garbage collection runs, unused refc pointers are detected and refcount is reduced. At 0 binary will be freed. This means that if more than 1 process has seen certain large binary, ALL of them must have GC before memory is freed. If you use hibernate on processes, this problem is solved automatically by hibernate procedure, otherwise it may take long time before all processes in chain have had the GC. You can assist them and AFTER your processing has finished, call erlang:garbage_collect manually. m?n 19 sep. 2016 kl 17:26 skrev ??? : > > Hi, > > My question is about the binary memory usage. > I implemented a server which accepts Tcp connection. All the Tcp > connections use binary options. > > Before I set up 10000 Tcp connections to my server, the memory usage is as > below: > (node1@REDACTED)1> erlang:memory(). > [{total,100311433}, > {processes,24898112}, > {processes_used,24895144}, > {system,75413321}, > {atom,1517705}, > {atom_used,1506108}, > {binary,3115928}, > {code,48956174}, > {ets,3556416}, > {maximum,102757346}] > > after I set up 10000 Tcp connections, every connection is hold by one > gen_server; the memory usage is as below: > (node1@REDACTED)5>erlang:memory(). > [{total,2616776425}, > {processes,92150752}, > {processes_used,92138976}, > {system,2524625673}, > {atom,1517705}, > {atom_used,1506108}, > {binary,2437117184}, > {code,48956174}, > {ets,13264464}, > {maximum,2848153566}] > > And I check the binary hold by all the processes on the node with the > command below: > List = [begin {binary, L} = erlang:process_info(P, binary), {P, > (lists:foldl(fun({_, I, _}, Acc) -> Acc + I end, 0, L))} end || P <- > processes() -- [self()]], lists:foldl(fun({_, A}, Acc) -> A + Acc end, 0, > List). > the result is 23113860. It is much less than the value 2437117184 reported > by erlang:memory(). > > My question is : > why does the VM allocate so much memory for binary? > Does the Tcp ports allocate their send/recv buffer on binary heap? > Is there any way I can see what are in the binary heap? > > Thanks, > BRs/Michael > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Mon Sep 19 17:53:47 2016 From: bob@REDACTED (Robert Wilkinson) Date: Mon, 19 Sep 2016 17:53:47 +0200 Subject: [erlang-questions] Apology In-Reply-To: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> Message-ID: <20160919155347.GA9134@fourtheye.org> On Mon, Sep 19, 2016 at 05:05:52PM +1200, ok@REDACTED wrote: > I have been taken to task in private e-mail by someone > who detected in my response to the "list comprehension puzzle" > both "aggressive sarcasm" and "undisguised contempt". > > In all honesty, no sarcasm was intended. (A sarcastic response > would not have pointed to the Erlang reference manual.) Nor > was any contempt whatsoever involved. I should not have to > reassure long-term readers of this mailing list that these > attitudes my critic claimed to detect were entirely imaginary. > > However, it shows that it was possible for people to misread > what I wrote. If anyone took offence at the message I > *meant* to be helpful, please accept my assurance that no > offence was intended and my unreserved apology for the offence. I would like to add my name to the list of people who are very happy with the contributions that you make to this mailing list. Bob P.S. Fortune cookie random and apposite :-) -- First law of debate: Never argue with a fool. People might not know the difference. From mfidelman@REDACTED Mon Sep 19 17:55:00 2016 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 19 Sep 2016 11:55:00 -0400 Subject: [erlang-questions] game engines? In-Reply-To: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> Message-ID: <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Thanks to all for your responses. Re. a couple of points here, might I ask a few follow-up questions: On 9/18/16 1:37 PM, Lutz Behnke wrote: > Hello, > > assigning each object in the game gets difficult for a number of > reasons, when trying to do this for an MMO, especially MMORPGs > (characterized by a very large number of objects, and active entities): > > You waste resources (CPU, RAM) when an object is currently not being > referenced by an active entity (e.g. a client connection, thus and > avatar or alternatively a Mob/NPC), since there is no other process > that will send any messages. Well yes, but is that not where Erlang shines - being able to maintain huge numbers of processes (or, in this case, little state machines)? > > More importantly, should you scale your engine to multiple hosts, you > either have to enforce a single process, requiring all updates and > query messages to be routed to this proc. Or you will have to build > some master/slave or peer to peer logic, which will ensure consistency > in the face of CAP. I'm actually thinking about military simulation - where the model is essentially: - every simulator (e.g., a flight sim, or a tank) is running on its own machine, complete with local world model and image generation (necessary to keep up with jitter-free image generation during high-g turns - you don't want pilots to puke all over the simulators) - there's a lot of dead reckoning going on locally - the only things that cross the network are deltas and events, generally sent by multicast - everything is synchronized by GPS time-stamp I discovered Erlang when I realized that we (the company I worked for) took a very different approach for simulating "virtual forces" (think non-player characters) - when we simulated 1000 tanks, on one machine, each tank would be an object, and we had 4 threads winding their way through every object, 20 time a second. Turns out that the main loops are real spaghetti code that breaks every time a new property gets added to an object. I started wondering why we didn't just have a process per simulated object - essentially the way we treated the person-in-the-loop simulators. The answer, of course, being context switching overhead. Then, I discovered Erlang. And I started thinking - why not just have a process per object. > > Separating into a) the state of instances, which you can store in a > KV-store and have b) a pool of generic procs, that will process the > state with c) a set of modules that provides the logic for a > particular object allows to push the state to the appropriate host. > With a separate KV-store that can handle net-partition and node > failure, you gain even a good amount of fault-resilience. > > Please excuse me beating my own drum, but I have implemented a > prototype of such an engine > (http://dl.acm.org/citation.cfm?id=2577389&CFID=787355984&CFTOKEN=91169762). > Unfortunately, for legal reason, I cannot make the code publicly > available yet. Any chance of arranging a copy that's not behind a paywall? Thanks, Miles > > mfg lutz > > Am 18.09.2016 um 04:11 schrieb Miles Fidelman: >> Hi Folks, >> >> I'm curious, has anybody written an Erlang-based game engine that >> implements a process per game entity? >> >> I've been been finding various examples of Erlang being used to manage >> user sessions, and other aspects of MMORPGs - but nothing that simply >> does the obvious - treating each object, player, etc. as an Erlang >> process. >> >> Am I missing something? >> >> Thanks, >> >> Miles Fidelman >> >> > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Sep 19 18:28:59 2016 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 19 Sep 2016 18:28:59 +0200 Subject: [erlang-questions] Apology In-Reply-To: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> Message-ID: Richard My flabber is gasted. I read what I assumed the posts that you referred to and am truly puzzled. I could not detect anything that I construed as either aggressive or sarcastic. I remain very puzzled. /Joe On Mon, Sep 19, 2016 at 7:05 AM, wrote: > I have been taken to task in private e-mail by someone > who detected in my response to the "list comprehension puzzle" > both "aggressive sarcasm" and "undisguised contempt". > > In all honesty, no sarcasm was intended. (A sarcastic response > would not have pointed to the Erlang reference manual.) Nor > was any contempt whatsoever involved. I should not have to > reassure long-term readers of this mailing list that these > attitudes my critic claimed to detect were entirely imaginary. > > However, it shows that it was possible for people to misread > what I wrote. If anyone took offence at the message I > *meant* to be helpful, please accept my assurance that no > offence was intended and my unreserved apology for the offence. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ameretat.reith@REDACTED Mon Sep 19 19:14:28 2016 From: ameretat.reith@REDACTED (Ameretat Reith) Date: Mon, 19 Sep 2016 21:44:28 +0430 Subject: [erlang-questions] Inets socket_type, what's ip_comm and how order IPvX sockets? Message-ID: I'm using tsung and it open a HTTP server to give me good things by inets API [1] But it open just IPv6 sockets and TCP connections over IPv4 connections will fail. I looked into inets to find how it finds to open IPv4 or IPv6 sockets and saw socket_type which defaults to ip_comm. [2] What is this? Is this mean IPv4 or IPv6 if system support? Can I provide inets more information to listen to both IPv4 and IPv6? I think for listenning on both IPv4 and IPv6 using same port number, one should open two sockets and set REUSE_PORT option. Can inets understand this by looking to socket_type or something? Can I (in inets:start call) tell I wan't IPv4 sockets? Or tell inets lib totally forget about IPv6 and open IPv4 sockets always? 1: https://github.com/processone/tsung/blob/18a318884282a17f419850169aefec9bdd5fc2ac/src/tsung_controller/ts_controller_sup.erl#L118 2: https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/lib/inets/include/httpd.hrl#L31 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Sep 19 19:42:10 2016 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 19 Sep 2016 13:42:10 -0400 Subject: [erlang-questions] Apology In-Reply-To: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> Message-ID: <20160919174209.GF33990@fhebert-ltm2.internal.salesforce.com> On 09/19, ok@REDACTED wrote: >However, it shows that it was possible for people to misread >what I wrote. If anyone took offence at the message I >*meant* to be helpful, please accept my assurance that no >offence was intended and my unreserved apology for the offence. > Without commenting on the level of offensiveness people perceive in your original post, I want to commend you on what I perceive to be a healthy and civil response to this. Regards, Fred. From jesper.louis.andersen@REDACTED Mon Sep 19 19:47:04 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 19 Sep 2016 19:47:04 +0200 Subject: [erlang-questions] Apology In-Reply-To: References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> Message-ID: Hi, Rather than joining the choir outright, I do see the complainers point. Text is a poor medium at communicating intent and there are two ways one can read the post, where one indeed yield sarcasm and snide remarks. Fortunately, there is also intent, and having known Richard's writing for more than 10 years, I can assure you no malice was intended. He even made a post to apologize were it misunderstood. One mans aggresion is another mans Socratic teaching. Most people mean no harm in their writings. So I'd advise people to err on the side of misunderstanding, rather than on the side of rudeness. Of course, some people are genuinely rude, but they tend to be few and far in between. Finally, let me second Lo?c. There is a current tendency in general internet discourse toward people becoming more sensitive. That is, people err on the opposite side of what I advise above, and take offense at other people's writings whether it was the underlying intent or not. I think this view has a long-term chilling effect on communities: "I cannot give you the formula for success, but I can give you the formula for failure - which is: Try to please everybody." - Herbert Bayard Swope People are excruciatingly good at finding error with your writings[0]. You better get used to it. [0] As a regular blog poster, you simply know that once your post hits Hacker News, then there is someone, somewhere, who derives great pleasure and arousal from taking a single sentence--usually out of context--and stabbing it with a knife until it dies. Then, with glee they will rejoice having found you are not only wrong, but bloody inconsistent and factually no better than a brown-speckled slug, whatever that is. On Mon, Sep 19, 2016 at 6:28 PM, Joe Armstrong wrote: > Richard > > My flabber is gasted. > > I read what I assumed the posts that you referred to and am truly > puzzled. > > I could not detect anything that I construed as either aggressive > or sarcastic. > > I remain very puzzled. > > /Joe > > > On Mon, Sep 19, 2016 at 7:05 AM, wrote: > > I have been taken to task in private e-mail by someone > > who detected in my response to the "list comprehension puzzle" > > both "aggressive sarcasm" and "undisguised contempt". > > > > In all honesty, no sarcasm was intended. (A sarcastic response > > would not have pointed to the Erlang reference manual.) Nor > > was any contempt whatsoever involved. I should not have to > > reassure long-term readers of this mailing list that these > > attitudes my critic claimed to detect were entirely imaginary. > > > > However, it shows that it was possible for people to misread > > what I wrote. If anyone took offence at the message I > > *meant* to be helpful, please accept my assurance that no > > offence was intended and my unreserved apology for the offence. > > > > > > > > _______________________________________________ > > 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 > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Mon Sep 19 21:22:45 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 19 Sep 2016 15:22:45 -0400 (EDT) Subject: [erlang-questions] Apology Message-ID: <1474312965.50459872@apps.rackspace.com> Mea Culpa. I wrote the PRIVATE post that has led to this thread. And I do apologize to all on this list for whatever unpleasantness it has generated. As I've noted before, I am not a professional programmer. But I have struggled diligently over the past three years to learn what I need to know to develop a web application in Erlang that is critical to my indie publishing business. And I have many times over been the beneficiary of the expertise and kind generosity of folks on this list. I would never want to do anything to tarnish the good will and ever-helpful spirit that animates the many threads on this list. No excuse, but I was exhausted after a long and very frustrating day of Erlang programming when I posted my query re: list comprehensions and, subsequently, my private response to ROK's post. Within minutes of my first posting Dan Gudmundsson responded succinctly and insightfully. It was helpful and I thanked him. Then ROK's response popped up. The tone was quite contrary to Dan's. Perhaps there was/is projection on my part. But here are lines that set me off: --- "The documentation is very clear:" This line sounded to me like so many I've read on other programming threads: "Read the f___king documentation...", "Read the documentation stupid." Fact is I have and continue to spend hours and hours reading the Erlang documentation and much of it is still not clear to me. --- "Why would you ever have thought that S *might* be an integer? If you want a hexadecimal integer, section 3.2 is clear." Well, sorry, but in the heat and fatigue of trying to solve a problem I did not read section 3.2. And in reading it now it's not all that clear to me. But more, I knew S was not an integer. I was merely confirming it for sake of making my question as clear as possible. But, clearly, I wasn't clear enough. This is an outstanding example of how easily brief text exchanges can be misconstrued on the Internet. Hexadecimal integers never crossed my mind. -- "That would require us to read your mind. What did you expect to happen and why did you expect that?" Once again, this sounded in context like an admonishment from a middle school algebra teacher to a dense student. Dense I'll admit to. But my algebra days are far behind me. ROK then continues with Prolog and Haskell examples. By this point in the post it came across to me as "look how clever I am and you're not." In short, I'll apologize here publicly for my, perhaps, intemperate response to ROK. But I won't apologize for my motive: The tone of expert-to-noobie communication is a critical factor in fostering a vibrant programming community. I quite disagree that "aggressive sarcasm" is an appropriate pedagogical strategy. While I'm beyond the noobie phase, I do care deeply about the future of Erlang. And my reading of ROK's post, which admittedly may have been projection, came across with the kind of tone that, I fear, would turn noobies away. Best wishes to all, Lloyd ********************************************* My books: THE GOSPEL OF ASHES http://thegospelofashes.com Strength is not enough. Do they have the courage and the cunning? Can they survive long enough to save the lives of millions? FREEIN' PANCHO http://freeinpancho.com A community of misfits help a troubled boy find his way AYA TAKEO http://ayatakeo.com Star-crossed love, war and power in an alternative universe Available through Amazon or by request from your favorite bookstore ********************************************** From essen@REDACTED Mon Sep 19 22:18:50 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 19 Sep 2016 22:18:50 +0200 Subject: [erlang-questions] Apology In-Reply-To: <1474312965.50459872@apps.rackspace.com> References: <1474312965.50459872@apps.rackspace.com> Message-ID: <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> From reading ROK's post I get the feeling that he did not understand what you were trying to figure out, and so attempted to provide a detailed answer about every point. Reconstruct your thougths in hopes of clarifying things for you. ROK's questions may sound offensive. They're not. Sometimes we jump to conclusions without asking ourselves those questions. Sometimes they're even stupid questions. Yet we need to be reminded of those because it's only when asking the right questions that we correct our understanding. As for the documentation being very clear, it's very subjective. Nothing is ever "very clear" to everyone. On 09/19/2016 09:22 PM, lloyd@REDACTED wrote: > Mea Culpa. > > I wrote the PRIVATE post that has led to this thread. And I do apologize to all on this list for whatever unpleasantness it has generated. > > As I've noted before, I am not a professional programmer. But I have struggled diligently over the past three years to learn what I need to know to develop a web application in Erlang that is critical to my indie publishing business. And I have many times over been the beneficiary of the expertise and kind generosity of folks on this list. I would never want to do anything to tarnish the good will and ever-helpful spirit that animates the many threads on this list. > > No excuse, but I was exhausted after a long and very frustrating day of Erlang programming when I posted my query re: list comprehensions and, subsequently, my private response to ROK's post. > > Within minutes of my first posting Dan Gudmundsson responded succinctly and insightfully. It was helpful and I thanked him. > > Then ROK's response popped up. The tone was quite contrary to Dan's. Perhaps there was/is projection on my part. But here are lines that set me off: > > --- "The documentation is very clear:" > > This line sounded to me like so many I've read on other programming threads: "Read the f___king documentation...", "Read the documentation stupid." Fact is I have and continue to spend hours and hours reading the Erlang documentation and much of it is still not clear to me. > > --- "Why would you ever have thought that S *might* be an integer? If you want a hexadecimal integer, section 3.2 is clear." > > Well, sorry, but in the heat and fatigue of trying to solve a problem I did not read section 3.2. And in reading it now it's not all that clear to me. But more, I knew S was not an integer. I was merely confirming it for sake of making my question as clear as possible. But, clearly, I wasn't clear enough. > > This is an outstanding example of how easily brief text exchanges can be misconstrued on the Internet. Hexadecimal integers never crossed my mind. > > -- "That would require us to read your mind. What did you expect to happen and why did you expect that?" > > Once again, this sounded in context like an admonishment from a middle school algebra teacher to a dense student. Dense I'll admit to. But my algebra days are far behind me. > > ROK then continues with Prolog and Haskell examples. By this point in the post it came across to me as "look how clever I am and you're not." > > In short, I'll apologize here publicly for my, perhaps, intemperate response to ROK. > > But I won't apologize for my motive: > > The tone of expert-to-noobie communication is a critical factor in fostering a vibrant programming community. I quite disagree that "aggressive sarcasm" is an appropriate pedagogical strategy. > > While I'm beyond the noobie phase, I do care deeply about the future of Erlang. And my reading of ROK's post, which admittedly may have been projection, came across with the kind of tone that, I fear, would turn noobies away. > > Best wishes to all, > > Lloyd > > > ********************************************* > My books: > > THE GOSPEL OF ASHES > http://thegospelofashes.com > > Strength is not enough. Do they have the courage > and the cunning? Can they survive long enough to > save the lives of millions? > > FREEIN' PANCHO > http://freeinpancho.com > > A community of misfits help a troubled boy find his way > > AYA TAKEO > http://ayatakeo.com > > Star-crossed love, war and power in an alternative > universe > > Available through Amazon or by request from your > favorite bookstore > > > ********************************************** > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From shaobo.ye@REDACTED Mon Sep 19 18:11:07 2016 From: shaobo.ye@REDACTED (=?gb18030?B?0rbJ2bKo?=) Date: Tue, 20 Sep 2016 00:11:07 +0800 Subject: [erlang-questions] =?gb18030?q?Re=A3=BARe=3A__question_about_bina?= =?gb18030?q?ry_memory?= Message-ID: Hi, I didn't pass the binary message to the process on the local node, but to the process on the remote node, so there shouldn't be more than 2 processes on the local node hold the reference to the same binary. Is it possible that the gen_tcp socket allocate their buffer on the binary heap? Thanks, BRs/Michael ---????--- ???:"Dmytro Lytovchenko" ????:2016?9?19?(???) ??11:44 ???:"???";"erlang-questions"; ??: [erlang-questions] question about binary memory -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.behnke@REDACTED Mon Sep 19 20:49:37 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Mon, 19 Sep 2016 20:49:37 +0200 Subject: [erlang-questions] game engines? In-Reply-To: <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Message-ID: <9cd4cf1a-4f57-8c30-a5ae-45242e4115a8@informatik.haw-hamburg.de> Am 19.09.2016 um 17:55 schrieb Miles Fidelman: > Thanks to all for your responses. > > Re. a couple of points here, might I ask a few follow-up questions: First of: I hold the points of the previous reply by Michael Truog to be valid and wish I had made them to start with. I found that one process per client connection (PCs and NPCs alike) is insufficient to cleanly separate concerns. The improved version I am currently working on, has around 2-3 procs per connection. In addition, there is a large proc set that handles space partitions, regardless of the number of objects or entities that exist within these partitions. > > > On 9/18/16 1:37 PM, Lutz Behnke wrote: > >> Hello, >> >> assigning each object in the game gets difficult for a number of >> reasons, when trying to do this for an MMO, especially MMORPGs >> (characterized by a very large number of objects, and active entities): >> >> You waste resources (CPU, RAM) when an object is currently not being >> referenced by an active entity (e.g. a client connection, thus and >> avatar or alternatively a Mob/NPC), since there is no other process >> that will send any messages. > > Well yes, but is that not where Erlang shines - being able to maintain > huge numbers of processes (or, in this case, little state machines)? Yes, compared to the next point, this is a minor one, but each process will consume space. Especially if your objects have large amounts of state. It is not a limitation of Erlang. You are likely to run out of hardware memory before you run out of concurrent processes (you may have to twiddle with +P, though). Please see my assumption of "every object" below. > >> >> More importantly, should you scale your engine to multiple hosts, you >> either have to enforce a single process, requiring all updates and >> query messages to be routed to this proc. Or you will have to build >> some master/slave or peer to peer logic, which will ensure consistency >> in the face of CAP. > > I'm actually thinking about military simulation - where the model is > essentially: > > - every simulator (e.g., a flight sim, or a tank) is running on its own > machine, complete with local world model and image generation (necessary > to keep up with jitter-free image generation during high-g turns - you > don't want pilots to puke all over the simulators) > > - there's a lot of dead reckoning going on locally - the only things > that cross the network are deltas and events, generally sent by multicast > > - everything is synchronized by GPS time-stamp For this specific model (a federation of simulators) your approach is definitely the one I would use. You can trust the local simulators to enforce rules/physics and only need a blackboard to exchange state values, maybe provide a visibility/ Area-of-Interest-Management (AoIM). The applicable standard, High Level Architecture (HLA), uses exactly this modell. But you will have to trust the clients. Traditionally you will not have more than a few thousand entities, all of them active by themselves (entities/active objects vs. plain objects like a rock or a bag of treasure). I would think it unlikely that you need to have more than one game server/blackboard though. You will probably have to do some state merging logic to recover from lost updates, network partition, node fault or similar things. Also, IP multicast basically doesn't work for private end customers, but is IIRC quite common in military simulations. MMORPGs will usually have a much higher number of active objects (aka players), although they are traditionally split into shards and zones, so that only a small percentage can actually interact with each other. But the main difference is that avatars often are composite objects: The actual person plus all its equipment and things it caries around or even posses in a bank or such. And as each of these passive objects can have it own state, merging it all into the state of the avatar may be possible, but certainly very un-Erlangish (IMHO). [..] > > Any chance of arranging a copy that's not behind a paywall? Argll.. sorry: http://users.informatik.haw-hamburg.de/~ubicomp/arbeiten/papers/MMVE-14.pdf (and please don't mind the worst-case absolute latencies. The point was to establish the better than O(n^2) complexity of a large server count, not an high performance implementation ;-) ) mfg lutz > > > Thanks, > > Miles > > >> >> mfg lutz >> >> Am 18.09.2016 um 04:11 schrieb Miles Fidelman: >>> Hi Folks, >>> >>> I'm curious, has anybody written an Erlang-based game engine that >>> implements a process per game entity? >>> >>> I've been been finding various examples of Erlang being used to manage >>> user sessions, and other aspects of MMORPGs - but nothing that simply >>> does the obvious - treating each object, player, etc. as an Erlang >>> process. >>> >>> Am I missing something? >>> >>> Thanks, >>> >>> Miles Fidelman >>> >>> >> >> >> >> >> _______________________________________________ >> 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 > -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5006 bytes Desc: S/MIME Cryptographic Signature URL: From kennethlakin@REDACTED Mon Sep 19 23:40:26 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Mon, 19 Sep 2016 14:40:26 -0700 Subject: [erlang-questions] Inets socket_type, what's ip_comm and how order IPvX sockets? In-Reply-To: References: Message-ID: <14754d40-b5be-e76c-fef2-4c66472c502f@gmail.com> On 09/19/2016 10:14 AM, Ameretat Reith wrote: > Can I (in inets:start call) tell I wan't IPv4 sockets? I'm pretty sure that adding the tuple {bind_address, {0,0,0,0}} to the property list in the inets:start call [0] will create an HTTP server that listens for only IPv4 requests. (Feel free to replace the IPv4 ANY address with a real address if you only want to listen on a particular interface.) I have no idea how to fix your problem with tseung, though. [0] The prop list is the second argument to the inets:start function. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sashang@REDACTED Tue Sep 20 03:46:38 2016 From: sashang@REDACTED (Sashan Govender) Date: Tue, 20 Sep 2016 11:46:38 +1000 Subject: [erlang-questions] Apology In-Reply-To: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> References: <85138b369b7f552967dd91acd5bced27.squirrel@chasm.otago.ac.nz> Message-ID: One of the things I've learned when writing responses to questions is not to use rhetorical questions. For example 'what do you think?' can come across as condescending, depending on the reader, and especially if you have spent 4 hours at home thinking about this after working 8 hours in your day job. Personally mailing lists and forums are the last place I go to find and answer and I only use them when I've exhausted my will to find the answer elsewhere, either by reading documentation, writing some test code, or reading someone else's code. Almost all those options are preferable to me. Additionally people on this list are not the type of people to have not tried. They are on this list out of curiosity and interest in Erlang, so by default you should assume that they have thought about the problem before posting to the list. Rhetorical questions work better in a face to face dialogue when trying to employ the Socratic method (for example see here: http://www.garlikov.com/Soc_Meth.html) to elicit from the other person what they might already know but haven't realized, however, in a face to face dialogue the tone in the voice also carries meaning and a question like 'what do you think?' in that context comes with a tone that is lost in a written email. Asked in person, a question like 'what do you think?' conveys that you value that person's opinion. In an email, the tone of voice isn't there and the question can be misconstrued. Avoid subjective statements like 'the documentation is very clear'. It doesn't add anything and doesn't serve any purpose. The person asking the question wouldn't have asked if it was 'very clear'. To be honest, it's pretty similar to RTFM. 'That would require us to read your mind' is contradictory given that you engaged in mind reading a few sentences above with "Why would you ever have thought that S *might* be an integer?" It's also reminiscent of something similar to what the alpha geeks at school would have said behind a snigger, but that's just my perception, biased by my personal life experience. Phrases that work as jokes in real life amongst friends lose their meaning on mailing lists with strangers. On Mon, Sep 19, 2016 at 3:05 PM, wrote: > I have been taken to task in private e-mail by someone > who detected in my response to the "list comprehension puzzle" > both "aggressive sarcasm" and "undisguised contempt". > > In all honesty, no sarcasm was intended. (A sarcastic response > would not have pointed to the Erlang reference manual.) Nor > was any contempt whatsoever involved. I should not have to > reassure long-term readers of this mailing list that these > attitudes my critic claimed to detect were entirely imaginary. > > However, it shows that it was possible for people to misread > what I wrote. If anyone took offence at the message I > *meant* to be helpful, please accept my assurance that no > offence was intended and my unreserved apology for the offence. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Tue Sep 20 04:26:50 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 20 Sep 2016 14:26:50 +1200 Subject: [erlang-questions] Apology In-Reply-To: <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: On 20/09/16 8:18 AM, Lo?c Hoguin wrote: >> > As for the documentation being very clear, it's very subjective. Nothing > is ever "very clear" to everyone. Fair point. There are actually two issues, of course. FINDING the documentation is the first thing. Searching for "Erlang documentation" quickly turns up https://www.erlang.org/docs. That says Erlang Reference Manual - User's Guide A user's guide System principles and efficiency guide which looks like an editing error. If you follow the link you find the reference manual, not the system principles or efficiency guide. A reference manual and user's guide being different things, it would be better if this said something like Erlang Reference Manual Defines Erlang's syntax, built-in data types, preprocessor, error handling, processes, and more. It would also be better if when you clicked on the link it didn't say Erlang Reference Manual User's Guide (which sounds like a user's guide to using the reference manual) but something like Erlang Reference Manual {An abstract} because the eye is drawn to the big blank space where there's just a copyright notice, rather than to the navbar. I can't speak for anyone else, but whenever I go to that page I have several nervous seconds while wondering if I've come to the right place. I personally find it confusing that "Escape Sequences" comes after "Boolean" rather than after "String" or "Atom". Perhaps the most helpful thing in https://www.erlang.org/docs is Learn You Some Erlang for Great Good! Learn You Some Erlang for Great Good! by Fred Hebert is a beginner's book about Erlang, published in 2013. It is available in paper copies and online. I have a copy of that book. While it is a good book for beginners, it isn't just for beginners. I have to be honest here: when it first came out I *hated* the title. Stupid, stupid, stupid. "Don't judge a book by its cover!" Actually reading the book taught me, well, not exactly stuff I hadn't found elsewhere, but how to *use* a lot of stuff I hadn't bothered with. Someone who reads that book will not be a beginner for long. We are blessed with a lot of good books about Erlang. I don't want to rank them. But I do think that the documentation page might want to draw special attention to this book because people CAN read it on-line. For example, three clicks get to you an explanation of strings. The second issue is UNDERSTANDING the documentation when you find it. The problem for writers is striking a balance between being concise and being patronising. I remember putting a lot of effort into writing a document for the BSI/ISO Prolog committee explaining a particular issue and some alternatives, and being told that it had been completely ignored because it was too long. There's a series of books, originally "The Little Lisper" which I personally experienced as offensively patronising (and so culture-bound it wasn't funny, though it tried to be). Yet for many people it was an EXCELLENT introduction to Lisp and Scheme and they loved the humour. The current reference manual tries to be reassuringly informal (for beginners) and timesavingly brief (for experienced users). Perhaps these r?les should be split between two different documents? Or maybe an idea from MTW https://en.wikipedia.org/wiki/Gravitation_(book) could be adopted: the text of that book is divided into "Track 1" (beginner level) and "Track 2" (more advanced) and the corners of the pages are coloured so you know which is which. (About 35 years after buying it, I'm still on track 1. Sigh. It's a great book for long flights: I am guaranteed *never* to finish it. Sigh.) Hey, maybe we could get Fred H?bert to write the "Erlang Reference Manual for Beginners" (:-). From hgisinger@REDACTED Tue Sep 20 05:01:45 2016 From: hgisinger@REDACTED (Hernando Gisinger) Date: Tue, 20 Sep 2016 00:01:45 -0300 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <1474217782.958230279@apps.rackspace.com> References: <1474217782.958230279@apps.rackspace.com> Message-ID: Hello 1> IsDigit = fun(C) -> C >= $0 andalso C =< $9 end. #Fun 2> S = "123a456". "123a456" 3> [IsDigit(I) || I <- S]. [true,true,true,false,true,true,true] 2016-09-18 13:56 GMT-03:00 : > Hello, > > Now this I would not expect: > > 4> S = "123a456". > "123a456" > > 5> is_integer(S). > false > > 6> [is_integer(I) || I <- S]. > [true,true,true,true,true,true,true] > > Please tell me what I don't understand. > > Many thanks, > > LRP > > > ********************************************* > My books: > > THE GOSPEL OF ASHES > http://thegospelofashes.com > > Strength is not enough. Do they have the courage > and the cunning? Can they survive long enough to > save the lives of millions? > > FREEIN' PANCHO > http://freeinpancho.com > > A community of misfits help a troubled boy find his way > > AYA TAKEO > http://ayatakeo.com > > Star-crossed love, war and power in an alternative > universe > > Available through Amazon or by request from your > favorite bookstore > > > ********************************************** > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Sep 20 06:38:09 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 20 Sep 2016 00:38:09 -0400 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: So, I'm relieved and pleased that this thread is veering in a constructive direction. And I salute Richard for giving it a nudge. Erlang documentation has been a frequent topic of conversation for as long as I've been following this list. On the one hand colossal work has been invested by many to produce what we have. I, for one, extend hearty thanks. On the other hand, many of us find nitpicks that loom large when we're trying to solve a problem, turn to the docs, but don't find the guidance we're looking for and need. Given my limited programming experience, the docs have been far more helpful than not, but four things have now and again vexed me: 1. Lack of context; e.g. why a library or function is useful; what real world problems can I solve with it? In some cases there is discussion, but so technical it flies over my head. 2. Excessive abstraction/concision. This is great for folks with mathematics training and cast of mind. But my literary sensibilities go tilt. 3. Too few or less-than-clear illustrative code fragments 4. Insufficient guidance on how to think through and design non-trivial Erlang programs. In some areas it feels like the docs were written to REMIND users of what they already know, e.g. as reference rather than teaching material. So, no doubt every one of my vexations may well reflect my personal lack of experience with both Erlang and other programming languages. So we're left with two hard problems: 1. What should we assume about the consumers of Erlang documentation? Perhaps these assumptions should be explicit throughout the docs. 2. How can we iteratively improve the docs given voluntary resources and busy lives? One hypothesis: 1. Writing software documentation that serves every consumer and every need may well be an impossible task. I have purchased and studied every one of the Erlang books and taken much from each of them. I also often search for tutorials to help understand this issue or that. But I think it's safe to assume that official Erlang docs are the first go-to place for folks with immediate questions that need answers. And one last question: 1. Can improved documentation be an effective tool for expanding and invigorating the Erlang community? All the best, Lloyd Sent from my iPad > On Sep 19, 2016, at 10:26 PM, Richard A. O'Keefe wrote: > > > > On 20/09/16 8:18 AM, Lo?c Hoguin wrote: >> As for the documentation being very clear, it's very subjective. Nothing >> is ever "very clear" to everyone. > > Fair point. > There are actually two issues, of course. > > FINDING the documentation is the first thing. > Searching for "Erlang documentation" quickly turns up > https://www.erlang.org/docs. > That says > Erlang Reference Manual - User's Guide > A user's guide System principles and efficiency guide > which looks like an editing error. If you follow the > link you find the reference manual, not the system > principles or efficiency guide. > A reference manual and user's guide being different > things, it would be better if this said something like > > Erlang Reference Manual > Defines Erlang's syntax, built-in data types, > preprocessor, error handling, processes, and more. > > It would also be better if when you clicked on the link > it didn't say > > Erlang Reference Manual User's Guide > > (which sounds like a user's guide to using the reference > manual) but something like > > Erlang Reference Manual > {An abstract} > > because the eye is drawn to the big blank space where > there's just a copyright notice, rather than to the navbar. > I can't speak for anyone else, but whenever I go to that > page I have several nervous seconds while wondering if I've > come to the right place. > > I personally find it confusing that "Escape Sequences" > comes after "Boolean" rather than after "String" or "Atom". > > Perhaps the most helpful thing in > https://www.erlang.org/docs > is > Learn You Some Erlang for Great Good! > Learn You Some Erlang for Great Good! by Fred Hebert > is a beginner's book about Erlang, published in 2013. > It is available in paper copies and online. > > I have a copy of that book. While it is a good book > for beginners, it isn't just for beginners. I have to > be honest here: when it first came out I *hated* the > title. Stupid, stupid, stupid. "Don't judge a book > by its cover!" Actually reading the book taught me, > well, not exactly stuff I hadn't found elsewhere, but > how to *use* a lot of stuff I hadn't bothered with. > Someone who reads that book will not be a beginner for long. > > We are blessed with a lot of good books about Erlang. > I don't want to rank them. But I do think that the > documentation page might want to draw special attention > to this book because people CAN read it on-line. For > example, three clicks get to you an explanation of strings. > > The second issue is UNDERSTANDING the documentation when > you find it. The problem for writers is striking a > balance between being concise and being patronising. > I remember putting a lot of effort into writing a > document for the BSI/ISO Prolog committee explaining a > particular issue and some alternatives, and being told > that it had been completely ignored because it was too > long. There's a series of books, originally "The Little > Lisper" which I personally experienced as offensively > patronising (and so culture-bound it wasn't funny, though > it tried to be). Yet for many people it was an EXCELLENT > introduction to Lisp and Scheme and they loved the humour. > > The current reference manual tries to be reassuringly > informal (for beginners) and timesavingly brief (for > experienced users). Perhaps these r?les should be > split between two different documents? Or maybe an > idea from MTW https://en.wikipedia.org/wiki/Gravitation_(book) > could be adopted: the text of that book is divided into > "Track 1" (beginner level) and "Track 2" (more advanced) > and the corners of the pages are coloured so you know which > is which. (About 35 years after buying it, I'm still on > track 1. Sigh. It's a great book for long flights: I am > guaranteed *never* to finish it. Sigh.) > > Hey, maybe we could get Fred H?bert to write the > "Erlang Reference Manual for Beginners" (:-). > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lloyd@REDACTED Tue Sep 20 06:41:47 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 20 Sep 2016 00:41:47 -0400 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> Message-ID: Hi Hernando, I came up with almost the exact same code after Dan Gudmunsson pointed out the error of my ways. Many thanks for the solution. Best wishes, Lloyd Sent from my iPad > On Sep 19, 2016, at 11:01 PM, Hernando Gisinger wrote: > > Hello > > 1> IsDigit = fun(C) -> C >= $0 andalso C =< $9 end. > #Fun > 2> S = "123a456". > "123a456" > 3> [IsDigit(I) || I <- S]. > [true,true,true,false,true,true,true] > > > 2016-09-18 13:56 GMT-03:00 : >> Hello, >> >> Now this I would not expect: >> >> 4> S = "123a456". >> "123a456" >> >> 5> is_integer(S). >> false >> >> 6> [is_integer(I) || I <- S]. >> [true,true,true,true,true,true,true] >> >> Please tell me what I don't understand. >> >> Many thanks, >> >> LRP >> >> >> ********************************************* >> My books: >> >> THE GOSPEL OF ASHES >> http://thegospelofashes.com >> >> Strength is not enough. Do they have the courage >> and the cunning? Can they survive long enough to >> save the lives of millions? >> >> FREEIN' PANCHO >> http://freeinpancho.com >> >> A community of misfits help a troubled boy find his way >> >> AYA TAKEO >> http://ayatakeo.com >> >> Star-crossed love, war and power in an alternative >> universe >> >> Available through Amazon or by request from your >> favorite bookstore >> >> >> ********************************************** >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From random.outcomes@REDACTED Tue Sep 20 07:07:02 2016 From: random.outcomes@REDACTED (Luke) Date: Tue, 20 Sep 2016 15:07:02 +1000 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: Good documentation is designed for readability, that goes beyond just content - it includes layout, organisation and definitely aesthetics. The Erlang docs are a virtualized printout, not an interactive guide on how to use a programming language. Look at the difference in these two pages. http://erlang.org/doc/design_principles/applications.html vs http://elixir-lang.org/docs/stable/elixir/Application.html Why doesn't anyone ever mention that the docs just look crap? It's easy to fix, and would make a massive difference on the impression new devs get about Erlang. These days programmers have largely become accustomed to a certain look and feel, and have an intuition on how to dig for what they're trying to find which doesn't stem from a time when you would turn to the back of the printout and scan down the index, apologies to the E/// greybeards in the list :P The underlying issue of terse or inadequate explanation would take longer to fix, I think allowing pull requests would be a big step forward. Also, what's with the multiple PDFs - you have a user manual, getting started guide, reference manual, probably more that I can't remember right now. There has got to be a way to just combine these into a single portal that all developers can refer back to. Lots of good information has been kept in this mailing list, so mails from it often come up in Google. Tell me, how quickly did you find the answer on this page http://erlang.org/pipermail/erlang-questions/2007-May/026655.html compared to this one http://stackoverflow.com/questions/2065990/defining-erlang-functions-in-the-shell I'm not a novice programmer - I had been coding for 10 years when I picked up Erlang with a masters in Software Eng, and immediately fell in love with the language, but with such an expert community behind it I think it's been a while since somebody who didn't intimately understand everything about Erlang in detail gave feedback on the experience for new developers. On Tue, Sep 20, 2016 at 2:38 PM, Lloyd R. Prentice wrote: > So, I'm relieved and pleased that this thread is veering in a constructive > direction. And I salute Richard for giving it a nudge. > > Erlang documentation has been a frequent topic of conversation for as long > as I've been following this list. On the one hand colossal work has been > invested by many to produce what we have. I, for one, extend hearty thanks. > On the other hand, many of us find nitpicks that loom large when we're > trying to solve a problem, turn to the docs, but don't find the guidance > we're looking for and need. Given my limited programming experience, the > docs have been far more helpful than not, but four things have now and > again vexed me: > > 1. Lack of context; e.g. why a library or function is useful; what real > world problems can I solve with it? In some cases there is discussion, but > so technical it flies over my head. > > 2. Excessive abstraction/concision. This is great for folks with > mathematics training and cast of mind. But my literary sensibilities go > tilt. > > 3. Too few or less-than-clear illustrative code fragments > > 4. Insufficient guidance on how to think through and design non-trivial > Erlang programs. > > In some areas it feels like the docs were written to REMIND users of what > they already know, e.g. as reference rather than teaching material. So, no > doubt every one of my vexations may well reflect my personal lack of > experience with both Erlang and other programming languages. > > So we're left with two hard problems: > > 1. What should we assume about the consumers of Erlang documentation? > Perhaps these assumptions should be explicit throughout the docs. > > 2. How can we iteratively improve the docs given voluntary resources and > busy lives? > > One hypothesis: > > 1. Writing software documentation that serves every consumer and every > need may well be an impossible task. > > I have purchased and studied every one of the Erlang books and taken much > from each of them. I also often search for tutorials to help understand > this issue or that. But I think it's safe to assume that official Erlang > docs are the first go-to place for folks with immediate questions that need > answers. > > And one last question: > > 1. Can improved documentation be an effective tool for expanding and > invigorating the Erlang community? > > All the best, > > Lloyd > > > Sent from my iPad > > > On Sep 19, 2016, at 10:26 PM, Richard A. O'Keefe > wrote: > > > > > > > > On 20/09/16 8:18 AM, Lo?c Hoguin wrote: > >> As for the documentation being very clear, it's very subjective. Nothing > >> is ever "very clear" to everyone. > > > > Fair point. > > There are actually two issues, of course. > > > > FINDING the documentation is the first thing. > > Searching for "Erlang documentation" quickly turns up > > https://www.erlang.org/docs. > > That says > > Erlang Reference Manual - User's Guide > > A user's guide System principles and efficiency guide > > which looks like an editing error. If you follow the > > link you find the reference manual, not the system > > principles or efficiency guide. > > A reference manual and user's guide being different > > things, it would be better if this said something like > > > > Erlang Reference Manual > > Defines Erlang's syntax, built-in data types, > > preprocessor, error handling, processes, and more. > > > > It would also be better if when you clicked on the link > > it didn't say > > > > Erlang Reference Manual User's Guide > > > > (which sounds like a user's guide to using the reference > > manual) but something like > > > > Erlang Reference Manual > > {An abstract} > > > > because the eye is drawn to the big blank space where > > there's just a copyright notice, rather than to the navbar. > > I can't speak for anyone else, but whenever I go to that > > page I have several nervous seconds while wondering if I've > > come to the right place. > > > > I personally find it confusing that "Escape Sequences" > > comes after "Boolean" rather than after "String" or "Atom". > > > > Perhaps the most helpful thing in > > https://www.erlang.org/docs > > is > > Learn You Some Erlang for Great Good! > > Learn You Some Erlang for Great Good! by Fred Hebert > > is a beginner's book about Erlang, published in 2013. > > It is available in paper copies and online. > > > > I have a copy of that book. While it is a good book > > for beginners, it isn't just for beginners. I have to > > be honest here: when it first came out I *hated* the > > title. Stupid, stupid, stupid. "Don't judge a book > > by its cover!" Actually reading the book taught me, > > well, not exactly stuff I hadn't found elsewhere, but > > how to *use* a lot of stuff I hadn't bothered with. > > Someone who reads that book will not be a beginner for long. > > > > We are blessed with a lot of good books about Erlang. > > I don't want to rank them. But I do think that the > > documentation page might want to draw special attention > > to this book because people CAN read it on-line. For > > example, three clicks get to you an explanation of strings. > > > > The second issue is UNDERSTANDING the documentation when > > you find it. The problem for writers is striking a > > balance between being concise and being patronising. > > I remember putting a lot of effort into writing a > > document for the BSI/ISO Prolog committee explaining a > > particular issue and some alternatives, and being told > > that it had been completely ignored because it was too > > long. There's a series of books, originally "The Little > > Lisper" which I personally experienced as offensively > > patronising (and so culture-bound it wasn't funny, though > > it tried to be). Yet for many people it was an EXCELLENT > > introduction to Lisp and Scheme and they loved the humour. > > > > The current reference manual tries to be reassuringly > > informal (for beginners) and timesavingly brief (for > > experienced users). Perhaps these r?les should be > > split between two different documents? Or maybe an > > idea from MTW https://en.wikipedia.org/wiki/Gravitation_(book) > > could be adopted: the text of that book is divided into > > "Track 1" (beginner level) and "Track 2" (more advanced) > > and the corners of the pages are coloured so you know which > > is which. (About 35 years after buying it, I'm still on > > track 1. Sigh. It's a great book for long flights: I am > > guaranteed *never* to finish it. Sigh.) > > > > Hey, maybe we could get Fred H?bert to write the > > "Erlang Reference Manual for Beginners" (:-). > > _______________________________________________ > > 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 kennethlakin@REDACTED Tue Sep 20 08:13:58 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Mon, 19 Sep 2016 23:13:58 -0700 Subject: [erlang-questions] Erlang documentation (was: Apology) In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> On 09/19/2016 10:07 PM, Luke wrote: > Why doesn't anyone ever mention that the docs just look crap? I'm fond of how the docs look and -for the most part- reasonably pleased with how they're organized. (In particular, the /doc/man/$MODULE.html structure is _absolutely killer_ for reference documentation.) IMO, the quality and general completeness of the Erlang reference manuals is what most projects should strive to emulate in their API documentation. > These days programmers have largely become accustomed to a > certain look and feel... I _really_ don't like how a _lot_ of "modern" documentation is laid out. If you're looking for inspiration, a _really_ impressive reference manual + user's guide (that -undoubtedly- took a _ton_ of work to put together) is the Postgresql documentation. > I think allowing pull requests would be a big step forward. https://github.com/erlang/otp/pulls I know for a fact that documentation updates are accepted. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From petergi@REDACTED Tue Sep 20 08:34:31 2016 From: petergi@REDACTED (Peter J Etheridge) Date: Tue, 20 Sep 2016 16:34:31 +1000 Subject: [erlang-questions] Learning from the Manual Message-ID: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> Dear List,I assume the Manual is clear to those who understand it. For noobies [like me], the Manual can be re-read and still not explain 'why' or 'how', or answer a question.Clearly, the Manual needs to be read in conjunction with ROK's email responses.Noobies only learn from Dan & ROK's informative answers when someone as game as Lloyd asks questions.I try to imagine Joe's idea of URL's or UUID's somehow linking the Manual to Roger's stash of ROK's answers. Might the Manual be improved by some FAQ in each module? -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Sep 20 09:00:11 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 20 Sep 2016 09:00:11 +0200 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: On 09/20/2016 07:07 AM, Luke wrote: > Look at the difference in these two pages. > > http://erlang.org/doc/design_principles/applications.html > > vs > > http://elixir-lang.org/docs/stable/elixir/Application.html > > Why doesn't anyone ever mention that the docs just look crap? You're comparing a user guide page from Erlang to a function reference page from Elixir. The equivalent Erlang page is http://erlang.org/doc/man/application.html And I'll echo Kenneth, the Erlang one is definitely better in my opinion. I'm not even sure why the function is described twice in the Elixir docs (title and spec). And not needing to go back at the top to select another function is very convenient. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From bchesneau@REDACTED Tue Sep 20 09:01:08 2016 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 20 Sep 2016 07:01:08 +0000 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: without counting we have erldocs.com On Tue, 20 Sep 2016 at 09:00, Lo?c Hoguin wrote: > On 09/20/2016 07:07 AM, Luke wrote: > > Look at the difference in these two pages. > > > > http://erlang.org/doc/design_principles/applications.html > > > > vs > > > > http://elixir-lang.org/docs/stable/elixir/Application.html > > > > Why doesn't anyone ever mention that the docs just look crap? > > You're comparing a user guide page from Erlang to a function reference > page from Elixir. The equivalent Erlang page is > http://erlang.org/doc/man/application.html > > And I'll echo Kenneth, the Erlang one is definitely better in my > opinion. I'm not even sure why the function is described twice in the > Elixir docs (title and spec). And not needing to go back at the top to > select another function is very convenient. > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > 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 Tue Sep 20 09:04:35 2016 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 20 Sep 2016 09:04:35 +0200 Subject: [erlang-questions] Inets socket_type, what's ip_comm and how order IPvX sockets? In-Reply-To: References: Message-ID: Hi! 2016-09-19 19:14 GMT+02:00 Ameretat Reith : > I'm using tsung and it open a HTTP server to give me good things by inets > API > [1] But it open just IPv6 sockets and TCP connections over IPv4 > connections > will fail. I looked into inets to find how it finds to open IPv4 or IPv6 > sockets and saw socket_type which defaults to ip_comm. [2] What is this? > This is a legacy name. It does not imply ipv4 or ipv6 it implies not SSL/TLS or HTTP as opposed to HTTPS. There is an *ipfamily option that you can set to get inet or inet6. * Regards Ingela Erlang/OTP team - Ericsson AB Is this > mean IPv4 or IPv6 if system support? Can I provide inets more information > to > listen to both IPv4 and IPv6? > > I think for listenning on both IPv4 and IPv6 using same port number, one > should > open two sockets and set REUSE_PORT option. Can inets understand this by > looking to socket_type or something? Can I (in inets:start call) tell I > wan't > IPv4 sockets? Or tell inets lib totally forget about IPv6 and open IPv4 > sockets > always? > > 1: https://github.com/processone/tsung/blob/18a318884282a17f419850169aefec > 9bdd5fc2ac/src/tsung_controller/ts_controller_sup.erl#L118 > > 2: https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904ce > a9e932e7dc/lib/inets/include/httpd.hrl#L31 > > _______________________________________________ > 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 Tue Sep 20 09:07:41 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 20 Sep 2016 09:07:41 +0200 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: On 09/20/2016 06:38 AM, Lloyd R. Prentice wrote: > 4. Insufficient guidance on how to think through and design non-trivial Erlang programs. This is the main problem with Erlang documentation. We have great reference manuals. We have good user guides (between bad and great depending on the application, but mostly good). We have virtually no tutorials outside books. I recommend reading this and fully understanding it when talking about documentation: https://jacobian.org/writing/great-documentation/ In particular the first part, what to write, describes what is expected from each and how they help. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From ameretat.reith@REDACTED Tue Sep 20 09:04:50 2016 From: ameretat.reith@REDACTED (Ameretat Reith) Date: Tue, 20 Sep 2016 11:34:50 +0430 Subject: [erlang-questions] =?iso-8859-1?q?Inets_socket=5Ftype=2C_what=27s?= =?iso-8859-1?q?_ip=5Fcomm_and_how_order_IPvX_sockets=3F?= In-Reply-To: <14754d40-b5be-e76c-fef2-4c66472c502f@gmail.com> References: <14754d40-b5be-e76c-fef2-4c66472c502f@gmail.com> Message-ID: <331bab62-f09a-4655-bf07-76478d8da14d@gmail.com> On Tuesday, September 20, 2016 2:10:26 AM IRDT, Kenneth Lakin wrote: > On 09/19/2016 10:14 AM, Ameretat Reith wrote: >> Can I (in inets:start call) tell I wan't IPv4 sockets? > > I'm pretty sure that adding the tuple > > {bind_address, {0,0,0,0}} > > to the property list in the inets:start call [0] will create an HTTP > server that listens for only IPv4 requests. (Feel free to replace the > IPv4 ANY address with a real address if you only want to listen on a > particular interface.) Thanks. Strangely I can see now tsung opens IPv4 sockets: tcp 0 0 10.0.3.148:8091 0.0.0.0:* LISTEN But packets won't responded, tcpdump: 06:59:04.480107 IP gw.60546 > 10.0.3.148.8091: Flags [S], seq 2442667145, win 27200, options [mss 1360,sackOK,TS val 4075095 ecr 0,nop,wscale 7], length 0 06:59:04.728993 IP gw.60548 > 10.0.3.148.8091: Flags [S], seq 2593659205, win 27200, options [mss 1360,sackOK,TS val 4075345 ecr 0,nop,wscale 7], length 0 From ingela.andin@REDACTED Tue Sep 20 09:25:15 2016 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 20 Sep 2016 09:25:15 +0200 Subject: [erlang-questions] Stopping a process with its supervision subtree In-Reply-To: <20160919091426.GA22246@circlewave.net> References: <92DCBCE1-B759-4E50-86FA-DC7488632A52@gmail.com> <20160919091426.GA22246@circlewave.net> Message-ID: Hi! 2016-09-19 11:14 GMT+02:00 Jachym Holecek : > Hi, > > # Dmitry Kolesnikov 2016-09-14: > > This is a good question! I?d like to get other's opinion on the subject > as well. > > I would go with following pattern: > > > > * S_X is {one_for_all, 0, 1} and all its child are permanent. > > * The process P_2 just {stop, normal, State} when the job is done. > > > > I do not like to ?leak? a knowledge of supervisor to child processes. > I?ll try to > > avoid usage of supervisor:terminate_child(?). On another hand, this > pattern has > > disadvantage. You?ll see a ?supervisor? S_X crash in the log when P_2 > stops due to > > ?permanent? property. > > Not knowing the full use case at hand I'll say that supervisors are > generally used > to manage the long-lived part of process hierarchy. It is a perfectly > reasonable > and common pattern to have a process manage its own children without > supervisors, > using just links and/or trap_exit and/or monitors. So when your > "management" pro- > cess terminates its auxiliary processes are shut down as well. That's why > these > primitives are built into the language after all. > > Supervisors is not only useful for restarts, they are also useful for clean process management. Used to gracefully stop applications making sure all application processes indeed are closed. Also if you do soft upgrade "by the book" the supervisors will be used to suspend processes before performing the upgrade instructions. I use monitors for processes that I need to interact with that are not part of my application. Links are the primitives used to implement supervisors. > Feel free to elaborate more precisely on what you're trying to do and why, > in case > the above doesn't seem helpful. > > > The usage of simple_one_to_one supervisor seems to be right for this > type of > > use-cases but it misses concept of related processes. > > I think simple_one_to_one supervisors are something of a historical > mistake, their > behaviour differes noticeably from the normal supervision strategies > (enough so to > come across as an inconsistency) and the functionality they offer is > ridiculously > easy to implement oneself in a way that exactly matches the use case at > hand, not > complicating things with unnecessary abstractions. > > I do not think they are a mistake, I think they where a missed use case and then added add hock, maybe without enough design considerations. Just because it is easy, it does not necessarily mean you should reinvent the wheel. Regards Ingela Erlang/OTP team - Ericsson AB > BR, > -- Jachym > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameretat.reith@REDACTED Tue Sep 20 09:20:39 2016 From: ameretat.reith@REDACTED (Ameretat Reith) Date: Tue, 20 Sep 2016 11:50:39 +0430 Subject: [erlang-questions] =?iso-8859-1?q?Inets_socket=5Ftype=2C_what=27s?= =?iso-8859-1?q?_ip=5Fcomm_and_how_order_IPvX_sockets=3F?= In-Reply-To: References: Message-ID: <99d569ca-7811-4461-a437-a43cb906b043@gmail.com> Sorry for multiple mails list, I and mail client became crazy at the same time. > This is a legacy name. It does not imply ipv4 or ipv6 it implies not > SSL/TLS or > HTTP as opposed to HTTPS. > > There is an > *ipfamily option that you can set to get inet or inet6. * Thanks. So, going back to first mail questions, the only thing that is not currently possibe is getting one inets listenning on both IPv4 and IPv6, correct? So It looks like a task of inets user (tsung) to conclude whether machine has IPv6 or IPv4 capabilites and open correct listenning socket. It was nice if inets did this and user could use services in an IP agnostinc way, imho. From roger@REDACTED Tue Sep 20 10:20:31 2016 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 20 Sep 2016 09:20:31 +0100 Subject: [erlang-questions] Erlang documentation (was: Apology) In-Reply-To: <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: On 20 September 2016 at 07:13, Kenneth Lakin wrote: > I'm fond of how the docs look and -for the most part- reasonably pleased > with how they're organized. (In particular, the /doc/man/$MODULE.html > structure is _absolutely killer_ for reference documentation.) I *do* wish that -- somehow -- the docs could be marked up so that a Google search would jump directly to the appropriate function. Some of the pages *almost* work: searching for "erlang element" returns the erlang(3) page, with (in the snippet) direct links to (e.g.) erlang:system_flag(dirty_cpu_schedulers_online). This is wrong, but encouraging (inasmuch as it says that Google understands anchors, and that some extra tags might fix it). On the other hand, searching for "erlang lists flatmap" takes you only to the top of the "lists" page. I have no idea how to make this work, however. From jose.valim@REDACTED Tue Sep 20 10:26:10 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Tue, 20 Sep 2016 10:26:10 +0200 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: > You're comparing a user guide page from Erlang to a function reference > page from Elixir. The equivalent Erlang page is > http://erlang.org/doc/man/application.html I agree with many on this thread. I find Erlang documentation excellent in terms of completeness. I love the user guides and reference manuals. But they are hard to discover and there is very little guidance on how they should be consumed. For example, take this page: http://erlang.org/doc/design_principles/des_princ.html Who is this guide written for? Does it have any pre-requisites? What am I expected to learn by the end of it? If this is not the guide I am looking for, where can I find other guides? When talking about module and function references, there are other areas for improvement. We don't have a search mechanism on the official docs and that's problematic because modules are split throughout multiple applications. I find myself constantly changing the URL in the address bar in order to navigate between modules in different applications because it is never clear how to do that from a given module page. I am sure it is possible to do it and I have done that before but on every day usage I still struggle with navigating the docs even after working on Erlang for 5 years. Another area that could be improved in the Erlang documentation is including examples of using modules and functions. Even in essential modules, such as the lists one, I would estimate only half of the functions have actual examples. Links from the docs to the source code can be useful for learning purposes and links from the docs to the documentation source can help boost contributions. > And I'll echo Kenneth, the Erlang one is definitely better in my opinion. > I'm not even sure why the function is described twice in the Elixir docs > (title and spec). If you are trying to answer which one is better you are missing the point. Instead look at Elixir docs (or any other project really) and see which ideas you can borrow to improve the Erlang documentation. And not needing to go back at the top to select another function is very > convenient. You can navigate all module functions using the sidebar on the left after clicking on "Functions". However, I am assuming this was not clear so I have opened an issue to fix that in future releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil@REDACTED Tue Sep 20 10:28:11 2016 From: ali.sabil@REDACTED (Ali Sabil) Date: Tue, 20 Sep 2016 08:28:11 +0000 Subject: [erlang-questions] Erlang documentation (was: Apology) In-Reply-To: <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: On Tue, Sep 20, 2016 at 8:14 AM Kenneth Lakin wrote: > On 09/19/2016 10:07 PM, Luke wrote: > > Why doesn't anyone ever mention that the docs just look crap? > > I'm fond of how the docs look and -for the most part- reasonably pleased > with how they're organized. (In particular, the /doc/man/$MODULE.html > structure is _absolutely killer_ for reference documentation.) IMO, the > quality and general completeness of the Erlang reference manuals is what > most projects should strive to emulate in their API documentation. > > While I agree that the erlang documentation content is great, its structure is only good if you know what you are looking for, it is certainly lacking in discoverability, this is its current high level structure: https://gist.github.com/asabil/76b30360afd4fec453b377e3e8ba77cc It is split in 3 different groups (Erlang/OTP, Applications and ERTS), which makes sense when you know what each one of them means. But for newcomers I think that the documentation fails at holding hands and walking you through the zoo that Erlang/OTP is :) My initial suggestion would be something more like this: https://gist.github.com/asabil/76b30360afd4fec453b377e3e8ba77cc#gistcomment-1878283 The second issue with the Erlang documentation is the visual aspect of it: it just feels a bit outdated :/ The typography and spacing would definitely need some improvement, and so do the various diagrams and illustrations. > > These days programmers have largely become accustomed to a > > certain look and feel... > > I _really_ don't like how a _lot_ of "modern" documentation is laid out. > If you're looking for inspiration, a _really_ impressive reference > manual + user's guide (that -undoubtedly- took a _ton_ of work to put > together) is the Postgresql documentation. > > Agreed, the PostgreSQL documentation is great, and we should aim for something similar. > > I think allowing pull requests would be a big step forward. > > https://github.com/erlang/otp/pulls > > I know for a fact that documentation updates are accepted. :) > I tried and I failed :/ The current documentation is built with magic, maybe I should try again? > _______________________________________________ > 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 Tue Sep 20 10:38:53 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 20 Sep 2016 10:38:53 +0200 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: <9148e834-8384-d299-e54b-2709ff2a3975@ninenines.eu> On 09/20/2016 10:26 AM, Jos? Valim wrote: > When talking about module and function references, there are other areas > for improvement. We don't have a search mechanism on the official docs > and that's problematic because modules are split throughout multiple > applications. I find myself constantly changing the URL in the address > bar in order to navigate between modules in different applications > because it is never clear how to do that from a given module page. We have a search and it is excellent. I have it bound to 'e' in my browser personally. Check on the right there: http://www.erlang.org/docs It will only show if you start searches first, and like you many people seem to fail to notice it. I get a feeling erldocs.com wouldn't exist if it was more prominent. > I am sure it is possible to do it and I have done that before but on > every day usage I still struggle with navigating the docs even after > working on Erlang for 5 years. Not anymore! It won't get you specific guide pages though, like the typespecs page, but you shouldn't have a problem finding functions anymore. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From mark.nijhof@REDACTED Tue Sep 20 10:39:35 2016 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Tue, 20 Sep 2016 08:39:35 +0000 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: I think one problem with the Erlang docs is that nobody does this: "However, I am assuming this was not clear so I have opened an issue to fix that in future releases." On Tue, 20 Sep 2016 at 10:26, Jos? Valim wrote: > > >> You're comparing a user guide page from Erlang to a function reference >> page from Elixir. The equivalent Erlang page is >> http://erlang.org/doc/man/application.html > > > I agree with many on this thread. I find Erlang documentation excellent in > terms of completeness. I love the user guides and reference manuals. But > they are hard to discover and there is very little guidance on how they > should be consumed. > > For example, take this page: > > http://erlang.org/doc/design_principles/des_princ.html > > Who is this guide written for? Does it have any pre-requisites? What am I > expected to learn by the end of it? If this is not the guide I am looking > for, where can I find other guides? > > When talking about module and function references, there are other areas > for improvement. We don't have a search mechanism on the official docs and > that's problematic because modules are split throughout multiple > applications. I find myself constantly changing the URL in the address bar > in order to navigate between modules in different applications because it > is never clear how to do that from a given module page. > > I am sure it is possible to do it and I have done that before but on every > day usage I still struggle with navigating the docs even after working on > Erlang for 5 years. > > Another area that could be improved in the Erlang documentation is > including examples of using modules and functions. Even in essential > modules, such as the lists one, I would estimate only half of the functions > have actual examples. Links from the docs to the source code can be useful > for learning purposes and links from the docs to the documentation source > can help boost contributions. > > >> And I'll echo Kenneth, the Erlang one is definitely better in my opinion. >> I'm not even sure why the function is described twice in the Elixir docs >> (title and spec). > > > If you are trying to answer which one is better you are missing the point. > Instead look at Elixir docs (or any other project really) and see which > ideas you can borrow to improve the Erlang documentation. > > And not needing to go back at the top to select another function is very >> convenient. > > > You can navigate all module functions using the sidebar on the left after > clicking on "Functions". However, I am assuming this was not clear so I > have opened an issue to fix that in future releases. > > _______________________________________________ > 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 Sep 20 10:42:47 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Tue, 20 Sep 2016 10:42:47 +0200 Subject: [erlang-questions] Apology In-Reply-To: <9148e834-8384-d299-e54b-2709ff2a3975@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <9148e834-8384-d299-e54b-2709ff2a3975@ninenines.eu> Message-ID: > > We have a search and it is excellent. I have it bound to 'e' in my browser > personally. Check on the right there: http://www.erlang.org/docs This is excellent, thank you! > It will only show if you start searches first, and like you many people > seem to fail to notice it. I get a feeling erldocs.com wouldn't exist if > it was more prominent. Agreed. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Tue, Sep 20, 2016 at 10:38 AM, Lo?c Hoguin wrote: > On 09/20/2016 10:26 AM, Jos? Valim wrote: > >> When talking about module and function references, there are other areas >> for improvement. We don't have a search mechanism on the official docs >> and that's problematic because modules are split throughout multiple >> applications. I find myself constantly changing the URL in the address >> bar in order to navigate between modules in different applications >> because it is never clear how to do that from a given module page. >> > > We have a search and it is excellent. I have it bound to 'e' in my browser > personally. Check on the right there: http://www.erlang.org/docs > > It will only show if you start searches first, and like you many people > seem to fail to notice it. I get a feeling erldocs.com wouldn't exist if > it was more prominent. > > I am sure it is possible to do it and I have done that before but on >> every day usage I still struggle with navigating the docs even after >> working on Erlang for 5 years. >> > > Not anymore! > > It won't get you specific guide pages though, like the typespecs page, but > you shouldn't have a problem finding functions anymore. > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Sep 20 10:43:37 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 20 Sep 2016 10:43:37 +0200 Subject: [erlang-questions] Apology In-Reply-To: <9148e834-8384-d299-e54b-2709ff2a3975@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <9148e834-8384-d299-e54b-2709ff2a3975@ninenines.eu> Message-ID: <42265057-c264-d94b-609f-9ea00206d021@ninenines.eu> On 09/20/2016 10:38 AM, Lo?c Hoguin wrote: > On 09/20/2016 10:26 AM, Jos? Valim wrote: >> When talking about module and function references, there are other areas >> for improvement. We don't have a search mechanism on the official docs >> and that's problematic because modules are split throughout multiple >> applications. I find myself constantly changing the URL in the address >> bar in order to navigate between modules in different applications >> because it is never clear how to do that from a given module page. > > We have a search and it is excellent. I have it bound to 'e' in my > browser personally. Check on the right there: http://www.erlang.org/docs > > It will only show if you start searches first, and like you many people > seem to fail to notice it. I get a feeling erldocs.com wouldn't exist if > it was more prominent. I replied too quickly; the first link on the page seems to be documentation with search, although it doesn't want to load for me at the moment (yet my binding still works). >> I am sure it is possible to do it and I have done that before but on >> every day usage I still struggle with navigating the docs even after >> working on Erlang for 5 years. > > Not anymore! > > It won't get you specific guide pages though, like the typespecs page, > but you shouldn't have a problem finding functions anymore. > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From kennethlakin@REDACTED Tue Sep 20 10:48:25 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Tue, 20 Sep 2016 01:48:25 -0700 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> On 09/20/2016 01:20 AM, Roger Lipscombe wrote: > I *do* wish that -- somehow -- the docs could be marked up so that a > Google search would jump directly to the appropriate function. It's a bit more typing (and not at all the same) but http://erlang.org/doc/man/lists.html#flatmap-2 works. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alin.popa@REDACTED Tue Sep 20 10:53:26 2016 From: alin.popa@REDACTED (Alin Popa) Date: Tue, 20 Sep 2016 09:53:26 +0100 Subject: [erlang-questions] Erlang documentation (was: Apology) In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: Worth mentioning that maybe there should be a version tag for each function/module saying when it was added? Happened to me few times already to realise that a particular function which was present in the documentation, was not available in my particular Erlang version, and I found out that only when running the tests (e.g. ets:update_counter/4 is not available in Erlang 17, but I can see it in here http://erlang.org/doc/man/ets.html#update_counter-4; and unless I'm missing something, it doesn't say when it was added). Alin On Tue, Sep 20, 2016 at 9:28 AM, Ali Sabil wrote: > > > On Tue, Sep 20, 2016 at 8:14 AM Kenneth Lakin > wrote: > >> On 09/19/2016 10:07 PM, Luke wrote: >> > Why doesn't anyone ever mention that the docs just look crap? >> >> I'm fond of how the docs look and -for the most part- reasonably pleased >> with how they're organized. (In particular, the /doc/man/$MODULE.html >> structure is _absolutely killer_ for reference documentation.) IMO, the >> quality and general completeness of the Erlang reference manuals is what >> most projects should strive to emulate in their API documentation. >> >> > While I agree that the erlang documentation content is great, its > structure is only good if you know what you are looking for, it is > certainly lacking in discoverability, this is its current high level > structure: https://gist.github.com/asabil/76b30360afd4fec453b377e3e8ba77cc > > It is split in 3 different groups (Erlang/OTP, Applications and ERTS), > which makes sense when you know what each one of them means. But for > newcomers I think that the documentation fails at holding hands and walking > you through the zoo that Erlang/OTP is :) My initial suggestion would be > something more like this: > https://gist.github.com/asabil/76b30360afd4fec453b377e3e8ba77 > cc#gistcomment-1878283 > > The second issue with the Erlang documentation is the visual aspect of it: > it just feels a bit outdated :/ The typography and spacing would definitely > need some improvement, and so do the various diagrams and illustrations. > > >> > These days programmers have largely become accustomed to a >> > certain look and feel... >> >> I _really_ don't like how a _lot_ of "modern" documentation is laid out. >> If you're looking for inspiration, a _really_ impressive reference >> manual + user's guide (that -undoubtedly- took a _ton_ of work to put >> together) is the Postgresql documentation. >> >> Agreed, the PostgreSQL documentation is great, and we should aim for > something similar. > > > >> > I think allowing pull requests would be a big step forward. >> >> https://github.com/erlang/otp/pulls >> >> I know for a fact that documentation updates are accepted. :) >> > > I tried and I failed :/ The current documentation is built with magic, > maybe I should try again? > > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Tue Sep 20 10:59:55 2016 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 20 Sep 2016 09:59:55 +0100 Subject: [erlang-questions] Erlang documentation In-Reply-To: <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> Message-ID: On 20 September 2016 at 09:48, Kenneth Lakin wrote: > It's a bit more typing (and not at all the same) but > > http://erlang.org/doc/man/lists.html#flatmap-2 Yeah, I get that there are section anchors in the documentation (which is amazingly useful), but it'd be nice if (somehow) Google could be taught to use them correctly (i.e. "not at all the same"; we're in agreement there). Typing "erlang lists flatmap" in my browser's search bar is less typing (as you say), and less error prone (I can never remember the /doc/man bit). Mind you, if the tab completion in the Erlang shell could display the names (and type specs) for parameters, rather than just the arity, I'd have to hit the documentation less frequently. I freely concede that this is probably (much) harder than it looks. From kennethlakin@REDACTED Tue Sep 20 11:00:34 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Tue, 20 Sep 2016 02:00:34 -0700 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: <40f5b3eb-810c-6cf6-23fe-38326d4677cf@gmail.com> On 09/20/2016 01:53 AM, Alin Popa wrote: > Worth mentioning that maybe there should be a version tag for each > function/module saying when it was added? Well, there *is* this: http://erlang.org/documentation/doc-8.0/doc/ http://erlang.org/documentation/doc-7.0/doc/ & etc with an index at http://erlang.org/documentation/ so you _can_ view just the docs for the ERTS rev that you've installed on your system. It _is_ less convenient than a "introduced in" tag in the latest documentation, though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mjtruog@REDACTED Tue Sep 20 11:04:28 2016 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 20 Sep 2016 02:04:28 -0700 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: <57E0FB9C.4080405@gmail.com> On 09/20/2016 01:53 AM, Alin Popa wrote: > Worth mentioning that maybe there should be a version tag for each function/module saying when it was added? Happened to me few times already to realise that a particular function which was present in the documentation, was not available in my particular Erlang version, and I found out that only when running the tests (e.g. ets:update_counter/4 is not available in Erlang 17, but I can see it in here http://erlang.org/doc/man/ets.html#update_counter-4; and unless I'm missing something, it doesn't say when it was added). Currently, we can use the external site http://erldocs.com/18.3/stdlib/ets.html?i=352 and change the version number in the URL to determine that the change occurred sometime in an 18.x release, but it would be nice to make things simpler. I have seen this be a problem more than once. From roger@REDACTED Tue Sep 20 11:07:58 2016 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 20 Sep 2016 10:07:58 +0100 Subject: [erlang-questions] Erlang documentation (was: Apology) In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: On 20 September 2016 at 09:53, Alin Popa wrote: > Worth mentioning that maybe there should be a version tag for each > function/module saying when it was added? erldocs.com allows you to view the documentation for a particular version (though I dislike erldocs.com for other reasons...). There's also the question of how long you treat functionality as "new". There are parts of the Erlang documentation that say things like "this changed in R5B". Does anyone still care? This is something that (again) the postgres documentation does right[1], if only Google would search only the current version (it's not always what you want, but at least it's predictable). [1] the top of the 9.5 documentation pages has "This page in other versions: 9.1 / 9.2 / 9.3 / 9.4 / current (9.5) | Development versions: devel / 9.6 | Unsupported versions: 7.2 / 7.3 / 7.4 / 8.0 / 8.1 / 8.2 / 8.3 / 8.4 / 9.0", which links as appropriate. From alin.popa@REDACTED Tue Sep 20 11:16:07 2016 From: alin.popa@REDACTED (Alin Popa) Date: Tue, 20 Sep 2016 10:16:07 +0100 Subject: [erlang-questions] Erlang documentation (was: Apology) In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: On Tue, Sep 20, 2016 at 10:07 AM, Roger Lipscombe wrote: > On 20 September 2016 at 09:53, Alin Popa wrote: > > Worth mentioning that maybe there should be a version tag for each > > function/module saying when it was added? > > erldocs.com allows you to view the documentation for a particular > version (though I dislike erldocs.com for other reasons...). I know there are workarounds to that, that's why I have bookmarks to the documentation for the version I'm using, but looking for a solution to something that in fact should help me find the solution to my initial problem, seems a bit wrong to me. Anyway, seems I'm not the only one hitting this issue. > There's > also the question of how long you treat functionality as "new". There > are parts of the Erlang documentation that say things like "this > changed in R5B". Does anyone still care? > > This is something that (again) the postgres documentation does > right[1], if only Google would search only the current version (it's > not always what you want, but at least it's predictable). > > [1] the top of the 9.5 documentation pages has "This page in other > versions: 9.1 / 9.2 / 9.3 / 9.4 / current (9.5) | Development > versions: devel / 9.6 | Unsupported versions: 7.2 / 7.3 / 7.4 / 8.0 > / 8.1 / 8.2 / 8.3 / 8.4 / 9.0", which links as appropriate. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Sep 20 11:27:23 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 20 Sep 2016 11:27:23 +0200 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: <9a45e69a-b0d0-7ad8-ff44-df5de58cfeab@ninenines.eu> This is something that I believe the PHP documentation does best. Every function page features a changelog, for example: https://secure.php.net/manual/en/function.htmlentities.php#refsect1-function.htmlentities-changelog Used to go back as far as PHP4; can't find any example of those at the moment, maybe it was dropped. While I wouldn't rank PHP the language very high in my list of favorites (other than how insanely easy it is to get started with it, even for people with no programming experience), the PHP documentation has been the best documentation I ever used. Out of the top of my head, in addition to the changelog, these are also very useful: * One page per function; debatable, but useful to pack more information * Detailed arguments and return values; not just typespecs (Erlang sometimes forces you to go up and down the page to find the full argument type, for example with the ssl module) * Examples! Many many examples * Related functions quickly discoverable; in the 'erlang' module it's hard to make out what relates to what * Comments; love them or hate them, they're useful to many developers * Input php.net/function-name in your browser and get the corresponding page directly I also notice that the layout improved since the last time I used it, and it seems easier to navigate nowadays. The entire documentation is easily accessible with a few clicks from any page; can't say the same for Erlang (try finding the Design Principles from the ssl reference page). The search field is also always visible, regardless of scrolling. I'm thinking I should get more inspiration from there for the Cowboy 2.0 documentation, especially for the function reference. One page per function with greater details, examples and links to related functions would be a great improvement I believe. On 09/20/2016 10:53 AM, Alin Popa wrote: > Worth mentioning that maybe there should be a version tag for each > function/module saying when it was added? Happened to me few times > already to realise that a particular function which was present in the > documentation, was not available in my particular Erlang version, and I > found out that only when running the tests (e.g. ets:update_counter/4 is > not available in Erlang 17, but I can see it in > here http://erlang.org/doc/man/ets.html#update_counter-4; and unless I'm > missing something, it doesn't say when it was added). > > Alin > > On Tue, Sep 20, 2016 at 9:28 AM, Ali Sabil > wrote: > > > > On Tue, Sep 20, 2016 at 8:14 AM Kenneth Lakin > > wrote: > > On 09/19/2016 10:07 PM, Luke wrote: > > Why doesn't anyone ever mention that the docs just look crap? > > I'm fond of how the docs look and -for the most part- reasonably > pleased > with how they're organized. (In particular, the > /doc/man/$MODULE.html > structure is _absolutely killer_ for reference documentation.) > IMO, the > quality and general completeness of the Erlang reference manuals > is what > most projects should strive to emulate in their API documentation. > > > While I agree that the erlang documentation content is great, its > structure is only good if you know what you are looking for, it is > certainly lacking in discoverability, this is its current high level > structure: https://gist.github.com/asabil/76b30360afd4fec453b377e3e8ba77cc > > > It is split in 3 different groups (Erlang/OTP, Applications and > ERTS), which makes sense when you know what each one of them means. > But for newcomers I think that the documentation fails at holding > hands and walking you through the zoo that Erlang/OTP is :) My > initial suggestion would be something more like this: > https://gist.github.com/asabil/76b30360afd4fec453b377e3e8ba77cc#gistcomment-1878283 > > > The second issue with the Erlang documentation is the visual aspect > of it: it just feels a bit outdated :/ The typography and spacing > would definitely need some improvement, and so do the various > diagrams and illustrations. > > > > These days programmers have largely become accustomed to a > > certain look and feel... > > I _really_ don't like how a _lot_ of "modern" documentation is > laid out. > If you're looking for inspiration, a _really_ impressive reference > manual + user's guide (that -undoubtedly- took a _ton_ of work > to put > together) is the Postgresql documentation. > > Agreed, the PostgreSQL documentation is great, and we should aim for > something similar. > > > > > I think allowing pull requests would be a big step forward. > > https://github.com/erlang/otp/pulls > > > I know for a fact that documentation updates are accepted. :) > > > I tried and I failed :/ The current documentation is built with > magic, maybe I should try again? > > > _______________________________________________ > 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 > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From carlsson.richard@REDACTED Tue Sep 20 11:39:02 2016 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 20 Sep 2016 11:39:02 +0200 Subject: [erlang-questions] A0 outperforming A>0, why? In-Reply-To: <1616165537.1589722.1473949651606@mail.yahoo.com> References: <1616165537.1589722.1473949651606.ref@mail.yahoo.com> <1616165537.1589722.1473949651606@mail.yahoo.com> Message-ID: The point of async IO threads is mainly to improve latency, not throughput. If many processes try to do a lot of I/O simultaneously, you want to make sure that they are never forced to wait for a long time because one of them is doing an unusually large I/O operation. However, managing the async I/O threads adds a little bit of overhead. If you're running a program where the only thing that matters is the total time from start to finish, on a single machine, and you don't care about the order in which individual processes get to do their work, then async I/O will not be particularly useful and mainly adds overhead. For example, in typical escripts it's a good idea to put %%! +A0 on the second or third line of the file. (Caveat: the OTP team have said that +A0 is not a regularly tested thing and you should probably not use it if uptime is important. For scripts, benchmarks etc., I see no reason to avoid it as long as you know what your tradeoffs are.) /Richard 2016-09-15 16:27 GMT+02:00 Vans S : > Running the rebar3 test suite, ct, passing A0 to the VM args is > consistently outperforming using any value of A above 0. The test suite > does over 1m iops. > > This should not be the be the case, is not the whole point of async > threads to improve io throughput? > > > The test can be setup by doing: > > install a package called time (apt-get install time) > > git clone https://github.com/erlang/rebar3.git > rebar3 install local > export REBAR3_ERL_ARGS="+A0 +K true" > time -v $(LOCAL_INSTALL_REBAR3_BIN) ct > export REBAR3_ERL_ARGS="+A1 +K true" > time -v $(LOCAL_INSTALL_REBAR3_BIN) ct > export REBAR3_ERL_ARGS="+A100 +K true" > time -v $(LOCAL_INSTALL_REBAR3_BIN) ct > > (rebar3 passes +sbtu as well) > > Here is an example of some results: > > %A0 > Command being timed: "/home/user/.cache/rebar3/bin/rebar3 ct" > User time (seconds): 203.63 > System time (seconds): 12.12 > Percent of CPU this job got: 128% > Elapsed (wall clock) time (h:mm:ss or m:ss): 2:48.44 > Average shared text size (kbytes): 0 > Average unshared data size (kbytes): 0 > Average stack size (kbytes): 0 > Average total size (kbytes): 0 > Maximum resident set size (kbytes): 369744 > Average resident set size (kbytes): 0 > Major (requiring I/O) page faults: 0 > Minor (reclaiming a frame) page faults: 2710315 > Voluntary context switches: 215661 > Involuntary context switches: 219472 > Swaps: 0 > File system inputs: 40 > File system outputs: 1078936 > Socket messages sent: 0 > Socket messages received: 0 > Signals delivered: 0 > Page size (bytes): 4096 > Exit status: 0 > > %A1 > Command being timed: "/home/user/.cache/rebar3/bin/rebar3 ct" > User time (seconds): 221.73 > System time (seconds): 17.73 > Percent of CPU this job got: 134% > Elapsed (wall clock) time (h:mm:ss or m:ss): 2:57.55 > Average shared text size (kbytes): 0 > Average unshared data size (kbytes): 0 > Average stack size (kbytes): 0 > Average total size (kbytes): 0 > Maximum resident set size (kbytes): 418184 > Average resident set size (kbytes): 0 > Major (requiring I/O) page faults: 0 > Minor (reclaiming a frame) page faults: 2704281 > Voluntary context switches: 2307583 > Involuntary context switches: 306797 > Swaps: 0 > File system inputs: 48 > File system outputs: 1078928 > Socket messages sent: 0 > Socket messages received: 0 > Signals delivered: 0 > Page size (bytes): 4096 > Exit status: 0 > > > %A100 > Command being timed: "/home/user/.cache/rebar3/bin/rebar3 ct" > User time (seconds): 223.26 > System time (seconds): 18.20 > Percent of CPU this job got: 133% > Elapsed (wall clock) time (h:mm:ss or m:ss): 3:01.20 > Average shared text size (kbytes): 0 > Average unshared data size (kbytes): 0 > Average stack size (kbytes): 0 > Average total size (kbytes): 0 > Maximum resident set size (kbytes): 385492 > Average resident set size (kbytes): 0 > Major (requiring I/O) page faults: 0 > Minor (reclaiming a frame) page faults: 2651960 > Voluntary context switches: 2392798 > Involuntary context switches: 404162 > Swaps: 0 > File system inputs: 72 > File system outputs: 1078936 > Socket messages sent: 0 > Socket messages received: 0 > Signals delivered: 0 > Page size (bytes): 4096 > Exit status: 0 > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Tue Sep 20 11:54:26 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 20 Sep 2016 11:54:26 +0200 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: <20160920095426.GA91242@erix.ericsson.se> On Tue, Sep 20, 2016 at 10:26:10AM +0200, Jos? Valim wrote: : > When talking about module and function references, there are other areas > for improvement. We don't have a search mechanism on the official docs and > that's problematic because modules are split throughout multiple > applications. I find myself constantly changing the URL in the address bar > in order to navigate between modules in different applications because it > is never clear how to do that from a given module page. Application/Module/Function search: http://www.erlang.org/erldoc/ Or did you mean a full text search? And I use tabs a lot. First search from the link above, then middle click a new tab for pages I want to get back to. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From jesper.louis.andersen@REDACTED Tue Sep 20 11:56:23 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 20 Sep 2016 11:56:23 +0200 Subject: [erlang-questions] every process should have a URL In-Reply-To: References: Message-ID: On Fri, Sep 16, 2016 at 9:16 AM, Joe Armstrong wrote: > What would a Pid look like - a > {HostIP,PortNumber,NodeName,LocalPidinNode} tuple? > The problem with this is that HostIP, PortNumber and NodeName are mobile. They change their location over time as the machine is moved around and roam. In the modern network, this is a common thing to happen, so one has to handle this. Another problem is that there is no way to authenticate. I propose that a Node is identified by Curve25519 Public Key. Thus, an identity is {Curve25519PK, LocalPid} Dissemination of the PK is done either over a DHT (Kademlia, ...) which maps the PK to {IP, Port} pairs. Or it is using a P2P mesh network such as Secure Scuttlebutt. Once connected, you exchange messages in a mode of authentication, where you force a handshake, and verify that the other end is indeed the owner of the secret key behind the public key. This thwarts MITM attacks. Furthermore, if you use something such a CurveTun, you also get the advantage the connection has perfect forward secrecy. Given: * enacl * dht * curve_tun We have the parts for the DHT solution already. For the Secure ScuttleButt (ssb) solution, we have to write some code, but OTOH, we then also get access to a open mesh facebook social media network :) I may be writing an OCaml backend for the ssb network :) -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Tue Sep 20 11:59:07 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 20 Sep 2016 11:59:07 +0200 Subject: [erlang-questions] Erlang documentation In-Reply-To: <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> Message-ID: <20160920095906.GB91242@erix.ericsson.se> On Tue, Sep 20, 2016 at 01:48:25AM -0700, Kenneth Lakin wrote: > On 09/20/2016 01:20 AM, Roger Lipscombe wrote: > > I *do* wish that -- somehow -- the docs could be marked up so that a > > Google search would jump directly to the appropriate function. > > It's a bit more typing (and not at all the same) but > > http://erlang.org/doc/man/lists.html#flatmap-2 http://erlang.org/doc/search?q=lists:flatmap -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From jose.valim@REDACTED Tue Sep 20 12:07:41 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Tue, 20 Sep 2016 12:07:41 +0200 Subject: [erlang-questions] Apology In-Reply-To: <20160920095426.GA91242@erix.ericsson.se> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <20160920095426.GA91242@erix.ericsson.se> Message-ID: > > Application/Module/Function search: > > http://www.erlang.org/erldoc/ > > Or did you mean a full text search? > No, that's exactly what I wanted. I will make sure to point others to this page, thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Tue Sep 20 12:14:19 2016 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 20 Sep 2016 12:14:19 +0200 Subject: [erlang-questions] game engines? In-Reply-To: <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Message-ID: 2016-09-19 17:55 GMT+02:00 Miles Fidelman > I'm actually thinking about military simulation - where the model is > essentially: > > - every simulator (e.g., a flight sim, or a tank) is running on its own > machine, complete with local world model and image generation (necessary to > keep up with jitter-free image generation during high-g turns - you don't > want pilots to puke all over the simulators) > > - there's a lot of dead reckoning going on locally - the only things that > cross the network are deltas and events, generally sent by multicast > > - everything is synchronized by GPS time-stamp > > I discovered Erlang when I realized that we (the company I worked for) > took a very different approach for simulating "virtual forces" (think > non-player characters) - when we simulated 1000 tanks, on one machine, each > tank would be an object, and we had 4 threads winding their way through > every object, 20 time a second. Turns out that the main loops are real > spaghetti code that breaks every time a new property gets added to an > object. > > I started wondering why we didn't just have a process per simulated object > - essentially the way we treated the person-in-the-loop simulators. The > answer, of course, being context switching overhead. > > Then, I discovered Erlang. And I started thinking - why not just have a > process per object. > Back in the day, there was the Sim94 troop simulation project, which was pretty successful - and way before Erlang got multicore support: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.6023 This related master's thesis might also be of interest (oops, turns out I was the examiner): https://www.scribd.com/document/184935294/Design-Patterns-for-Simulations-in-Erlang I also found this newer work while searching, but I haven't read it myself: https://www.researchgate.net/publication/233985869_Parallel_Discrete_Event_Simulation_with_Erlang Finally, I found this, which made me double-check that I wasn't answering a post from 2012 :-) http://erlang.org/pipermail/erlang-questions/2012-March/065136.html /Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Tue Sep 20 12:18:40 2016 From: matthias@REDACTED (Matthias Lang) Date: Tue, 20 Sep 2016 12:18:40 +0200 Subject: [erlang-questions] Learning from the Manual In-Reply-To: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> References: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> Message-ID: <20160920101840.otsbzrmkzidkvzcn@corelatus.se> On 20. September 2016, Peter J Etheridge wrote: > Dear List,I assume the Manual is clear to those who understand it. > For noobies [like me], the Manual can be re-read and still not explain > 'why' or 'how', or answer a question.Clearly, the Manual needs to be > read in conjunction with ROK's email responses. If you're a "noobie", you _can_ learn Erlang from the reference manual. But it's hard work. Much easier to work through an entertaining and carefully thought out tutorial, i.e.: http://learnyousomeerlang.com/content I took a look at his "datatype" section to see how he dealt with the "there aren't actually any strings" problem. And it turns out there is no string section! Perfect. Instead, the "Lists!" section shows strings as one possible use of lists, which makes it a natural place to present all the pitfalls. I'm looking at: http://learnyousomeerlang.com/starting-out-for-real As someone who's written both manuals and FAQs, I think learn-you-some-erlang has an unbeatable effort/benefit ratio, especially for "noobies". Matt From mfidelman@REDACTED Tue Sep 20 14:12:58 2016 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 20 Sep 2016 08:12:58 -0400 Subject: [erlang-questions] game engines? In-Reply-To: References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Message-ID: <8ce477cd-00f0-2116-c5a0-fc92b59b76d8@meetinghouse.net> Thanks Richard. Now that's what I'm talking about! Miles On 9/20/16 6:14 AM, Richard Carlsson wrote: > 2016-09-19 17:55 GMT+02:00 Miles Fidelman > > > I'm actually thinking about military simulation - where the model > is essentially: > > - every simulator (e.g., a flight sim, or a tank) is running on > its own machine, complete with local world model and image > generation (necessary to keep up with jitter-free image generation > during high-g turns - you don't want pilots to puke all over the > simulators) > > - there's a lot of dead reckoning going on locally - the only > things that cross the network are deltas and events, generally > sent by multicast > > - everything is synchronized by GPS time-stamp > > I discovered Erlang when I realized that we (the company I worked > for) took a very different approach for simulating "virtual > forces" (think non-player characters) - when we simulated 1000 > tanks, on one machine, each tank would be an object, and we had 4 > threads winding their way through every object, 20 time a second. > Turns out that the main loops are real spaghetti code that breaks > every time a new property gets added to an object. > > I started wondering why we didn't just have a process per > simulated object - essentially the way we treated the > person-in-the-loop simulators. The answer, of course, being > context switching overhead. > > Then, I discovered Erlang. And I started thinking - why not just > have a process per object. > > > Back in the day, there was the Sim94 troop simulation project, which > was pretty successful - and way before Erlang got multicore support: > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.6023 > > This related master's thesis might also be of interest (oops, turns > out I was the examiner): > https://www.scribd.com/document/184935294/Design-Patterns-for-Simulations-in-Erlang > > I also found this newer work while searching, but I haven't read it > myself: > https://www.researchgate.net/publication/233985869_Parallel_Discrete_Event_Simulation_with_Erlang > > Finally, I found this, which made me double-check that I wasn't > answering a post from 2012 :-) > http://erlang.org/pipermail/erlang-questions/2012-March/065136.html > > /Richard > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Sep 20 14:14:22 2016 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 20 Sep 2016 08:14:22 -0400 Subject: [erlang-questions] Learning from the Manual In-Reply-To: <20160920101840.otsbzrmkzidkvzcn@corelatus.se> References: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> <20160920101840.otsbzrmkzidkvzcn@corelatus.se> Message-ID: And, I've found "Erlang and OTP in Action" to be very helpful in getting from the basics to the design of real systems. On 9/20/16 6:18 AM, Matthias Lang wrote: > On 20. September 2016, Peter J Etheridge wrote: > >> Dear List,I assume the Manual is clear to those who understand it. >> For noobies [like me], the Manual can be re-read and still not explain >> 'why' or 'how', or answer a question.Clearly, the Manual needs to be >> read in conjunction with ROK's email responses. > If you're a "noobie", you _can_ learn Erlang from the reference > manual. But it's hard work. Much easier to work through an > entertaining and carefully thought out tutorial, i.e.: > > http://learnyousomeerlang.com/content > > I took a look at his "datatype" section to see how he dealt with the > "there aren't actually any strings" problem. And it turns out there is > no string section! Perfect. Instead, the "Lists!" section shows > strings as one possible use of lists, which makes it a natural place > to present all the pitfalls. I'm looking at: > > http://learnyousomeerlang.com/starting-out-for-real > > As someone who's written both manuals and FAQs, I think > learn-you-some-erlang has an unbeatable effort/benefit ratio, > especially for "noobies". > > Matt > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From olivier.boudeville@REDACTED Tue Sep 20 15:36:17 2016 From: olivier.boudeville@REDACTED (BOUDEVILLE Olivier) Date: Tue, 20 Sep 2016 13:36:17 +0000 Subject: [erlang-questions] game engines? In-Reply-To: References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Message-ID: <399802326ea241d2a4ebdb4fb96e6d0b@PCYINTPEXMU011.NEOPROD.EDF.FR> Hi, In a somewhat related topic (large-scale discrete event simulation in Erlang) - and even it is a shameless plug, sorry for that - there is also Sim-Diasca (http://sim-diasca.com/), a discrete event simulation engine released as free software. The goal is to perform the simulation of complex systems in a multi-agent way, with scalability in mind (thus in a parallel and distributed manner); of course simulation and game engines share quite a lot of architectural and software traits. As for us, we used (and are still using) plain Erlang (not OTP, whether or not it is a good choice) and a lightweight layer above it to provide the object-oriented constructs we needed (multiple inheritance, polymorphism, etc.), on top of which the engine as such was built (to perform time synchronisation, support interactions and provide relevant properties like the respect of causality and reproducibility). In this setting each model instance is represented by exactly one Erlang process, and it proved to be quite scalable (of course synchronisation has a cost, and surely one shall not expect perfect speed-up with this kind of simulations). Back in 2010, we already exceeded 1 million interacting model instances in a single simulation (and the models involved were not specifically lightweight?). Recently this work received a bit of third-party positive feedback [1]. So IMHO such use of Erlang seems to be a very good solution to cover the needs you mentioned (moreover using it for that did not inflict much headache). Hope this helps, Olivier. [1] http://sbrc2016.ufba.br/downloads/Salao_Ferramentas/154234.pdf Olivier Boudeville EDF R&D, D?partement SINETICS, Groupe ASICS, Bureau O2-E10 7, Boulevard Gaspard Monge, 91120 Palaiseau, France T?l. : +33 (0)1 78 19 43 63 T?l. mobile : +33 (0)6 16 83 37 22 De : erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] Envoy? : mardi 20 septembre 2016 12:14 ? : mfidelman@REDACTED Cc : erlang-questions@REDACTED Objet : Re: [erlang-questions] game engines? 2016-09-19 17:55 GMT+02:00 Miles Fidelman > I'm actually thinking about military simulation - where the model is essentially: - every simulator (e.g., a flight sim, or a tank) is running on its own machine, complete with local world model and image generation (necessary to keep up with jitter-free image generation during high-g turns - you don't want pilots to puke all over the simulators) - there's a lot of dead reckoning going on locally - the only things that cross the network are deltas and events, generally sent by multicast - everything is synchronized by GPS time-stamp I discovered Erlang when I realized that we (the company I worked for) took a very different approach for simulating "virtual forces" (think non-player characters) - when we simulated 1000 tanks, on one machine, each tank would be an object, and we had 4 threads winding their way through every object, 20 time a second. Turns out that the main loops are real spaghetti code that breaks every time a new property gets added to an object. I started wondering why we didn't just have a process per simulated object - essentially the way we treated the person-in-the-loop simulators. The answer, of course, being context switching overhead. Then, I discovered Erlang. And I started thinking - why not just have a process per object. Back in the day, there was the Sim94 troop simulation project, which was pretty successful - and way before Erlang got multicore support: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.6023 This related master's thesis might also be of interest (oops, turns out I was the examiner): https://www.scribd.com/document/184935294/Design-Patterns-for-Simulations-in-Erlang I also found this newer work while searching, but I haven't read it myself: https://www.researchgate.net/publication/233985869_Parallel_Discrete_Event_Simulation_with_Erlang Finally, I found this, which made me double-check that I wasn't answering a post from 2012 :-) http://erlang.org/pipermail/erlang-questions/2012-March/065136.html /Richard 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 lloyd@REDACTED Tue Sep 20 15:44:30 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 20 Sep 2016 09:44:30 -0400 (EDT) Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> Message-ID: <1474379070.78336567@apps.rackspace.com> 'Lo again Hernando, Shortly after I responded to your post I realized that you might be interested in the problem that led to my list comprehension puzzler question: I'm working on a web application that requires users to enter International Standard Book Numbers (ISBNs). Thus I need a function to validate the format of user input. ISBNS are either 10 or 13-digits. The standard specifies a check-sum algorithm, but that seemed too complicated for my purposes. So, after struggling with the list comprehension puzzler and Dan Gudmundsson's helpful input, I came up with this: isbn_format_valid(ISBN) -> D = fun(I) -> (I >= $0) and (I =< 9) end, NotIntegers = [I || I <- ISBN, D(I) == true], Flag1 = NotIntegers == [], Flag2 = (length(ISBN) == 13) or (length(ISBN) == 10), Flag1 and Flag2. As you can see, our minds ran down the same track. There may be a faster, more elegant, way to solve the problem, but this seems to do the job. Now if I can only figure out how to use the Library of Congress API to retrieve book data... Thanks again for your post, Lloyd -----Original Message----- From: "Lloyd R. Prentice" Sent: Tuesday, September 20, 2016 12:41am To: "Hernando Gisinger" Cc: "erlang-questions@REDACTED" Subject: Re: [erlang-questions] List comprehension puzzler _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions Hi Hernando, I came up with almost the exact same code after Dan Gudmunsson pointed out the error of my ways. Many thanks for the solution. Best wishes, Lloyd Sent from my iPad > On Sep 19, 2016, at 11:01 PM, Hernando Gisinger wrote: > > Hello > > 1> IsDigit = fun(C) -> C >= $0 andalso C =< $9 end. > #Fun > 2> S = "123a456". > "123a456" > 3> [IsDigit(I) || I <- S]. > [true,true,true,false,true,true,true] > > > 2016-09-18 13:56 GMT-03:00 : >> Hello, >> >> Now this I would not expect: >> >> 4> S = "123a456". >> "123a456" >> >> 5> is_integer(S). >> false >> >> 6> [is_integer(I) || I <- S]. >> [true,true,true,true,true,true,true] >> >> Please tell me what I don't understand. >> >> Many thanks, >> >> LRP >> >> >> ********************************************* >> My books: >> >> THE GOSPEL OF ASHES >> http://thegospelofashes.com >> >> Strength is not enough. Do they have the courage >> and the cunning? Can they survive long enough to >> save the lives of millions? >> >> FREEIN' PANCHO >> http://freeinpancho.com >> >> A community of misfits help a troubled boy find his way >> >> AYA TAKEO >> http://ayatakeo.com >> >> Star-crossed love, war and power in an alternative >> universe >> >> Available through Amazon or by request from your >> favorite bookstore >> >> >> ********************************************** >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From ruel@REDACTED Tue Sep 20 16:17:36 2016 From: ruel@REDACTED (Pagayon, Ruel) Date: Tue, 20 Sep 2016 22:17:36 +0800 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <1474379070.78336567@apps.rackspace.com> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> Message-ID: Hello Lloyd, One thing to help optimise your code: Guards isbn_format_valid(ISBN) when length(ISBN) == 10 orelse length(ISBN) == 13 -> [I || I <- ISBN, I < $0 orelse I > $9] == []; isbn_format_valid(_ISBN) -> false. This makes your "is the number equal or between 0 and 9" only be executed if the length is 10 or 13. Reason for this, is if user inputs a very large list, you won't have to compare every character only to find later that it's not the right length (your machine will take the toll). Also, you may have noticed we replaced *or* with *orelse*, this makes the second expression be evaluated if the ISBN length isn't 10. Cheers, *Ruel Pagayon* - ruel@REDACTED Platform Engineer Networking and Communications On Tue, Sep 20, 2016 at 9:44 PM, wrote: > 'Lo again Hernando, > > Shortly after I responded to your post I realized that you might be > interested in the problem that led to my list comprehension puzzler > question: > > I'm working on a web application that requires users to enter > International Standard Book Numbers (ISBNs). Thus I need a function to > validate the format of user input. > > ISBNS are either 10 or 13-digits. The standard specifies a check-sum > algorithm, but that seemed too complicated for my purposes. So, after > struggling with the list comprehension puzzler and Dan Gudmundsson's > helpful input, I came up with this: > > isbn_format_valid(ISBN) -> > D = fun(I) -> (I >= $0) and (I =< 9) end, > NotIntegers = [I || I <- ISBN, D(I) == true], > Flag1 = NotIntegers == [], > Flag2 = (length(ISBN) == 13) or (length(ISBN) == 10), > Flag1 and Flag2. > > As you can see, our minds ran down the same track. > > There may be a faster, more elegant, way to solve the problem, but this > seems to do the job. Now if I can only figure out how to use the Library of > Congress API to retrieve book data... > > Thanks again for your post, > > Lloyd > > > > > -----Original Message----- > From: "Lloyd R. Prentice" > Sent: Tuesday, September 20, 2016 12:41am > To: "Hernando Gisinger" > Cc: "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] List comprehension puzzler > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > Hi Hernando, > > I came up with almost the exact same code after Dan Gudmunsson pointed out > the error of my ways. > > Many thanks for the solution. > > Best wishes, > > Lloyd > > Sent from my iPad > > > On Sep 19, 2016, at 11:01 PM, Hernando Gisinger > wrote: > > > > Hello > > > > 1> IsDigit = fun(C) -> C >= $0 andalso C =< $9 end. > > #Fun > > 2> S = "123a456". > > "123a456" > > 3> [IsDigit(I) || I <- S]. > > [true,true,true,false,true,true,true] > > > > > > 2016-09-18 13:56 GMT-03:00 : > >> Hello, > >> > >> Now this I would not expect: > >> > >> 4> S = "123a456". > >> "123a456" > >> > >> 5> is_integer(S). > >> false > >> > >> 6> [is_integer(I) || I <- S]. > >> [true,true,true,true,true,true,true] > >> > >> Please tell me what I don't understand. > >> > >> Many thanks, > >> > >> LRP > >> > >> > >> ********************************************* > >> My books: > >> > >> THE GOSPEL OF ASHES > >> http://thegospelofashes.com > >> > >> Strength is not enough. Do they have the courage > >> and the cunning? Can they survive long enough to > >> save the lives of millions? > >> > >> FREEIN' PANCHO > >> http://freeinpancho.com > >> > >> A community of misfits help a troubled boy find his way > >> > >> AYA TAKEO > >> http://ayatakeo.com > >> > >> Star-crossed love, war and power in an alternative > >> universe > >> > >> Available through Amazon or by request from your > >> favorite bookstore > >> > >> > >> ********************************************** > >> > >> _______________________________________________ > >> 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 felixgallo@REDACTED Tue Sep 20 16:21:38 2016 From: felixgallo@REDACTED (Felix Gallo) Date: Tue, 20 Sep 2016 07:21:38 -0700 Subject: [erlang-questions] Erlang documentation In-Reply-To: <20160920095906.GB91242@erix.ericsson.se> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> <20160920095906.GB91242@erix.ericsson.se> Message-ID: I believe there are similar products for windows, but one that I've found indispensable for osx is 'Dash', which is a documentation lookup and search tool that can be configured to pop up at a keystroke. It can include docs for all the major and most minor programming languages and tools, including erlang and elixir. It's much faster than browsing around by hand. On Sep 20, 2016 2:59 AM, "Raimo Niskanen" < raimo+erlang-questions@REDACTED> wrote: > On Tue, Sep 20, 2016 at 01:48:25AM -0700, Kenneth Lakin wrote: > > On 09/20/2016 01:20 AM, Roger Lipscombe wrote: > > > I *do* wish that -- somehow -- the docs could be marked up so that a > > > Google search would jump directly to the appropriate function. > > > > It's a bit more typing (and not at all the same) but > > > > http://erlang.org/doc/man/lists.html#flatmap-2 > > http://erlang.org/doc/search?q=lists:flatmap > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Sep 20 16:31:39 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 20 Sep 2016 10:31:39 -0400 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> Message-ID: Wow! I very much appreciate this improvement. Lloyd Sent from my iPad > On Sep 20, 2016, at 10:17 AM, Pagayon, Ruel wrote: > > Hello Lloyd, > > One thing to help optimise your code: Guards > > isbn_format_valid(ISBN) when length(ISBN) == 10 orelse length(ISBN) == 13 -> > [I || I <- ISBN, I < $0 orelse I > $9] == []; > > isbn_format_valid(_ISBN) -> > false. > > > This makes your "is the number equal or between 0 and 9" only be executed if the length is 10 or 13. Reason for this, is if user inputs a very large list, you won't have to compare every character only to find later that it's not the right length (your machine will take the toll). > > Also, you may have noticed we replaced or with orelse, this makes the second expression be evaluated if the ISBN length isn't 10. > > Cheers, > > > Ruel Pagayon - ruel@REDACTED > Platform Engineer > Networking and Communications > >> On Tue, Sep 20, 2016 at 9:44 PM, wrote: >> 'Lo again Hernando, >> >> Shortly after I responded to your post I realized that you might be interested in the problem that led to my list comprehension puzzler question: >> >> I'm working on a web application that requires users to enter International Standard Book Numbers (ISBNs). Thus I need a function to validate the format of user input. >> >> ISBNS are either 10 or 13-digits. The standard specifies a check-sum algorithm, but that seemed too complicated for my purposes. So, after struggling with the list comprehension puzzler and Dan Gudmundsson's helpful input, I came up with this: >> >> isbn_format_valid(ISBN) -> >> D = fun(I) -> (I >= $0) and (I =< 9) end, >> NotIntegers = [I || I <- ISBN, D(I) == true], >> Flag1 = NotIntegers == [], >> Flag2 = (length(ISBN) == 13) or (length(ISBN) == 10), >> Flag1 and Flag2. >> >> As you can see, our minds ran down the same track. >> >> There may be a faster, more elegant, way to solve the problem, but this seems to do the job. Now if I can only figure out how to use the Library of Congress API to retrieve book data... >> >> Thanks again for your post, >> >> Lloyd >> >> >> >> >> -----Original Message----- >> From: "Lloyd R. Prentice" >> Sent: Tuesday, September 20, 2016 12:41am >> To: "Hernando Gisinger" >> Cc: "erlang-questions@REDACTED" >> Subject: Re: [erlang-questions] List comprehension puzzler >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> Hi Hernando, >> >> I came up with almost the exact same code after Dan Gudmunsson pointed out the error of my ways. >> >> Many thanks for the solution. >> >> Best wishes, >> >> Lloyd >> >> Sent from my iPad >> >> > On Sep 19, 2016, at 11:01 PM, Hernando Gisinger wrote: >> > >> > Hello >> > >> > 1> IsDigit = fun(C) -> C >= $0 andalso C =< $9 end. >> > #Fun >> > 2> S = "123a456". >> > "123a456" >> > 3> [IsDigit(I) || I <- S]. >> > [true,true,true,false,true,true,true] >> > >> > >> > 2016-09-18 13:56 GMT-03:00 : >> >> Hello, >> >> >> >> Now this I would not expect: >> >> >> >> 4> S = "123a456". >> >> "123a456" >> >> >> >> 5> is_integer(S). >> >> false >> >> >> >> 6> [is_integer(I) || I <- S]. >> >> [true,true,true,true,true,true,true] >> >> >> >> Please tell me what I don't understand. >> >> >> >> Many thanks, >> >> >> >> LRP >> >> >> >> >> >> ********************************************* >> >> My books: >> >> >> >> THE GOSPEL OF ASHES >> >> http://thegospelofashes.com >> >> >> >> Strength is not enough. Do they have the courage >> >> and the cunning? Can they survive long enough to >> >> save the lives of millions? >> >> >> >> FREEIN' PANCHO >> >> http://freeinpancho.com >> >> >> >> A community of misfits help a troubled boy find his way >> >> >> >> AYA TAKEO >> >> http://ayatakeo.com >> >> >> >> Star-crossed love, war and power in an alternative >> >> universe >> >> >> >> Available through Amazon or by request from your >> >> favorite bookstore >> >> >> >> >> >> ********************************************** >> >> >> >> _______________________________________________ >> >> 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 Tue Sep 20 16:42:57 2016 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 20 Sep 2016 14:42:57 +0000 Subject: [erlang-questions] game engines? In-Reply-To: <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Message-ID: Erlang processes shine when they can run asynchronously and in a loosely coupled manner, so I am skeptical that a process-per-entity would work well where the entities need to run synchronously (20 times/sec) and interact heavily. For synchronous, interactive behavior I suspect the solution you currently have (thread iterating through objects) is simplest. I remember a discussion years ago about a simulation consisting of ants randomly moving from square to square on a chess board where only 1 ant is permitted on a square. The discussion revolved around process-per-ant and all the synchronization issues that it entailed. It turned out that flipping things inside out and using a process-per-*square* and representing the ants as messages passed between them worked out much better. There are many ways to use processes, and mapping them to your simulation's actors is not always best. Is there another way to apply many processes to a military sim? On Mon, Sep 19, 2016 at 10:55 AM Miles Fidelman wrote: > Thanks to all for your responses. > > Re. a couple of points here, might I ask a few follow-up questions: > > > On 9/18/16 1:37 PM, Lutz Behnke wrote: > > Hello, > > assigning each object in the game gets difficult for a number of reasons, > when trying to do this for an MMO, especially MMORPGs (characterized by a > very large number of objects, and active entities): > > You waste resources (CPU, RAM) when an object is currently not being > referenced by an active entity (e.g. a client connection, thus and avatar > or alternatively a Mob/NPC), since there is no other process that will send > any messages. > > > Well yes, but is that not where Erlang shines - being able to maintain > huge numbers of processes (or, in this case, little state machines)? > > > > More importantly, should you scale your engine to multiple hosts, you > either have to enforce a single process, requiring all updates and query > messages to be routed to this proc. Or you will have to build some > master/slave or peer to peer logic, which will ensure consistency in the > face of CAP. > > > I'm actually thinking about military simulation - where the model is > essentially: > > - every simulator (e.g., a flight sim, or a tank) is running on its own > machine, complete with local world model and image generation (necessary to > keep up with jitter-free image generation during high-g turns - you don't > want pilots to puke all over the simulators) > > - there's a lot of dead reckoning going on locally - the only things that > cross the network are deltas and events, generally sent by multicast > > - everything is synchronized by GPS time-stamp > > I discovered Erlang when I realized that we (the company I worked for) > took a very different approach for simulating "virtual forces" (think > non-player characters) - when we simulated 1000 tanks, on one machine, each > tank would be an object, and we had 4 threads winding their way through > every object, 20 time a second. Turns out that the main loops are real > spaghetti code that breaks every time a new property gets added to an > object. > > I started wondering why we didn't just have a process per simulated object > - essentially the way we treated the person-in-the-loop simulators. The > answer, of course, being context switching overhead. > > Then, I discovered Erlang. And I started thinking - why not just have a > process per object. > > > > Separating into a) the state of instances, which you can store in a > KV-store and have b) a pool of generic procs, that will process the state > with c) a set of modules that provides the logic for a particular object > allows to push the state to the appropriate host. With a separate KV-store > that can handle net-partition and node failure, you gain even a good amount > of fault-resilience. > > Please excuse me beating my own drum, but I have implemented a prototype > of such an engine ( > http://dl.acm.org/citation.cfm?id=2577389&CFID=787355984&CFTOKEN=91169762). > Unfortunately, for legal reason, I cannot make the code publicly available > yet. > > > Any chance of arranging a copy that's not behind a paywall? > > > Thanks, > > Miles > > > > mfg lutz > > Am 18.09.2016 um 04:11 schrieb Miles Fidelman: > > Hi Folks, > > I'm curious, has anybody written an Erlang-based game engine that > implements a process per game entity? > > I've been been finding various examples of Erlang being used to manage > user sessions, and other aspects of MMORPGs - but nothing that simply > does the obvious - treating each object, player, etc. as an Erlang > process. > > Am I missing something? > > Thanks, > > Miles Fidelman > > > > > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Tue Sep 20 16:57:13 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 20 Sep 2016 16:57:13 +0200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <1474379070.78336567@apps.rackspace.com> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> Message-ID: <20160920145713.GA3154@erix.ericsson.se> On Tue, Sep 20, 2016 at 09:44:30AM -0400, lloyd@REDACTED wrote: > 'Lo again Hernando, > > Shortly after I responded to your post I realized that you might be interested in the problem that led to my list comprehension puzzler question: > > I'm working on a web application that requires users to enter International Standard Book Numbers (ISBNs). Thus I need a function to validate the format of user input. > > ISBNS are either 10 or 13-digits. The standard specifies a check-sum algorithm, but that seemed too complicated for my purposes. So, after struggling with the list comprehension puzzler and Dan Gudmundsson's helpful input, I came up with this: > > isbn_format_valid(ISBN) -> > D = fun(I) -> (I >= $0) and (I =< 9) end, > NotIntegers = [I || I <- ISBN, D(I) == true], > Flag1 = NotIntegers == [], > Flag2 = (length(ISBN) == 13) or (length(ISBN) == 10), > Flag1 and Flag2. > > As you can see, our minds ran down the same track. > > There may be a faster, more elegant, way to solve the problem, but this seems to do the job. Now if I can only figure out how to use the Library of Congress API to retrieve book data... Small improvement, finish with: .... == true], L = length(ISBN), (NotIntegers == []) andalso ((L == 10) orelse (L == 13)). And, your fun() D would accept this: [1.0, 2.0, 3.0, ...] so write it as: D = fun(I) -> is_integer(I) andalso ($0 =< I) andalso (I =< $9) end, Your list comprehension can be replaced with: NotIntegers = lists:filter(D, ISBN), Resulting in (eliminating NotIntegers with a case statement): isbn_format_valid(ISBN) -> D = fun(I) -> is_integer(I) andalso ($0 =< I) andalso (I =< $9) end, case lists:filter(D, ISBN) of [] -> L = length(ISBN), (L == 10) orelse (L == 13); _ -> false end. Note that that will construct a result list with all non-integers just to check that it is empty, so a slimmer, faster solution would be to do it in plain function recursion: isbn_format_valid(ISBN) -> isbn_format_valid(ISBN, 0). %% isbn_format_valid([_|_], N) when N > 13 -> false isbn_format_valid([I|Is], N) if is_integer(I), $0 =< I, I =< $9 -> isbn_format_valid(Is, N+1); true -> false end; isbn_format_valid([], 10) -> true; isbn_format_valid([], 13) -> true; isbn_format_valid([], _) -> false. And here is a (God Forbid) regexp solution: isbn_format_valid(ISBN) -> case re:run(ISBN, "^(\\d{10}|\\d{13})$", [{capture,none}] of match -> true; nomatch -> false end. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-questions@REDACTED Tue Sep 20 17:00:18 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 20 Sep 2016 17:00:18 +0200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> Message-ID: <20160920150018.GB3154@erix.ericsson.se> On Tue, Sep 20, 2016 at 10:17:36PM +0800, Pagayon, Ruel wrote: > Hello Lloyd, > > One thing to help optimise your code: Guards > > isbn_format_valid(ISBN) when length(ISBN) == 10 orelse length(ISBN) == 13 -> > [I || I <- ISBN, I < $0 orelse I > $9] == []; > > isbn_format_valid(_ISBN) -> > false. > > > This makes your "is the number equal or between 0 and 9" only be executed > if the length is 10 or 13. Reason for this, is if user inputs a very large > list, you won't have to compare every character only to find later that > it's not the right length (your machine will take the toll). Note that length(ISBN) will be called twice on this maybe very long list, and that in itself may be bad since length/1 is O(N). See my do-it-with-plain-functions safer but more verbose example. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ewdpb@REDACTED Tue Sep 20 16:24:20 2016 From: ewdpb@REDACTED (=?UTF-8?Q?Wilmar_P=C3=A9rez?=) Date: Tue, 20 Sep 2016 10:24:20 -0400 Subject: [erlang-questions] Learning from the Manual Message-ID: Hi Peter I am in the same boat as you: very excited to learn Erlang but somehow finding clear information very cumbersome to get my hands on. Tutorials and many books (well, there are not that many), tend to stick to the basics or go right ahead to the overly complicated almost impossible to understand code. So far the most useful books I have found are "Programming Erlang" by Joe Armstrong and "Introducing Erlang" by Simon St. Laurent. If you find anything useful please send it my way. In an ideal world I would like to have something very similar to a university level course book with labs. Good luck with your learning Regards, Wilmar 2016-09-20 2:34 GMT-04:00 Peter J Etheridge : > Dear List, > I assume the Manual is clear to those who understand it. > For noobies [like me], the Manual can be re-read and still not explain > 'why' or 'how', or answer a question. > Clearly, the Manual needs to be read in conjunction with ROK's email > responses. > Noobies only learn from Dan & ROK's informative answers when someone as > game as Lloyd asks questions. > I try to imagine Joe's idea of URL's or UUID's somehow linking the Manual > to Roger's stash of ROK's answers. > Might the Manual be improved by some FAQ in each module? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trapexit@REDACTED Tue Sep 20 17:04:14 2016 From: trapexit@REDACTED (Antonio SJ Musumeci) Date: Tue, 20 Sep 2016 11:04:14 -0400 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> Message-ID: While in C... length(ISBN) would still be O(n) and possibly unbounded. I don't know if there is any optimization in the guard to cause the second length() to be skipped but that still seems expensive. Probably best to keep count while you check or maybe something ugly like isbn_format_valid([A,B,C,D,E,F,G,H,I,J|Tail]) -> check_A_to_J andalso isbn_sub_format_valid(Tail). isbn_format_valid(_) -> false. isbn_sub_format_valid([]) -> true; isbn_sub_format_valid([A,B,C]) -> check_A_to_C. On Tue, Sep 20, 2016 at 10:17 AM, Pagayon, Ruel wrote: > Hello Lloyd, > > One thing to help optimise your code: Guards > > isbn_format_valid(ISBN) when length(ISBN) == 10 orelse length(ISBN) == 13 > -> > [I || I <- ISBN, I < $0 orelse I > $9] == []; > > isbn_format_valid(_ISBN) -> > false. > > > This makes your "is the number equal or between 0 and 9" only be executed > if the length is 10 or 13. Reason for this, is if user inputs a very large > list, you won't have to compare every character only to find later that > it's not the right length (your machine will take the toll). > > Also, you may have noticed we replaced *or* with *orelse*, this makes the > second expression be evaluated if the ISBN length isn't 10. > > Cheers, > > > *Ruel Pagayon* - ruel@REDACTED > Platform Engineer > Networking and Communications > > On Tue, Sep 20, 2016 at 9:44 PM, wrote: > >> 'Lo again Hernando, >> >> Shortly after I responded to your post I realized that you might be >> interested in the problem that led to my list comprehension puzzler >> question: >> >> I'm working on a web application that requires users to enter >> International Standard Book Numbers (ISBNs). Thus I need a function to >> validate the format of user input. >> >> ISBNS are either 10 or 13-digits. The standard specifies a check-sum >> algorithm, but that seemed too complicated for my purposes. So, after >> struggling with the list comprehension puzzler and Dan Gudmundsson's >> helpful input, I came up with this: >> >> isbn_format_valid(ISBN) -> >> D = fun(I) -> (I >= $0) and (I =< 9) end, >> NotIntegers = [I || I <- ISBN, D(I) == true], >> Flag1 = NotIntegers == [], >> Flag2 = (length(ISBN) == 13) or (length(ISBN) == 10), >> Flag1 and Flag2. >> >> As you can see, our minds ran down the same track. >> >> There may be a faster, more elegant, way to solve the problem, but this >> seems to do the job. Now if I can only figure out how to use the Library of >> Congress API to retrieve book data... >> >> Thanks again for your post, >> >> Lloyd >> >> >> >> >> -----Original Message----- >> From: "Lloyd R. Prentice" >> Sent: Tuesday, September 20, 2016 12:41am >> To: "Hernando Gisinger" >> Cc: "erlang-questions@REDACTED" >> Subject: Re: [erlang-questions] List comprehension puzzler >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> Hi Hernando, >> >> I came up with almost the exact same code after Dan Gudmunsson pointed >> out the error of my ways. >> >> Many thanks for the solution. >> >> Best wishes, >> >> Lloyd >> >> Sent from my iPad >> >> > On Sep 19, 2016, at 11:01 PM, Hernando Gisinger >> wrote: >> > >> > Hello >> > >> > 1> IsDigit = fun(C) -> C >= $0 andalso C =< $9 end. >> > #Fun >> > 2> S = "123a456". >> > "123a456" >> > 3> [IsDigit(I) || I <- S]. >> > [true,true,true,false,true,true,true] >> > >> > >> > 2016-09-18 13:56 GMT-03:00 : >> >> Hello, >> >> >> >> Now this I would not expect: >> >> >> >> 4> S = "123a456". >> >> "123a456" >> >> >> >> 5> is_integer(S). >> >> false >> >> >> >> 6> [is_integer(I) || I <- S]. >> >> [true,true,true,true,true,true,true] >> >> >> >> Please tell me what I don't understand. >> >> >> >> Many thanks, >> >> >> >> LRP >> >> >> >> >> >> ********************************************* >> >> My books: >> >> >> >> THE GOSPEL OF ASHES >> >> http://thegospelofashes.com >> >> >> >> Strength is not enough. Do they have the courage >> >> and the cunning? Can they survive long enough to >> >> save the lives of millions? >> >> >> >> FREEIN' PANCHO >> >> http://freeinpancho.com >> >> >> >> A community of misfits help a troubled boy find his way >> >> >> >> AYA TAKEO >> >> http://ayatakeo.com >> >> >> >> Star-crossed love, war and power in an alternative >> >> universe >> >> >> >> Available through Amazon or by request from your >> >> favorite bookstore >> >> >> >> >> >> ********************************************** >> >> >> >> _______________________________________________ >> >> 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 ruel@REDACTED Tue Sep 20 17:14:51 2016 From: ruel@REDACTED (Pagayon, Ruel) Date: Tue, 20 Sep 2016 23:14:51 +0800 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <20160920150018.GB3154@erix.ericsson.se> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: > > Note that length(ISBN) will be called twice on this maybe very long list, > and that in itself may be bad since length/1 is O(N). > > See my do-it-with-plain-functions safer but more verbose example. Thanks for clearing that up! That definitely is a better way. Cheers, Ruel *Ruel Pagayon* - ruel@REDACTED Platform Engineer Networking and Communications On Tue, Sep 20, 2016 at 11:00 PM, Raimo Niskanen < raimo+erlang-questions@REDACTED> wrote: > On Tue, Sep 20, 2016 at 10:17:36PM +0800, Pagayon, Ruel wrote: > > Hello Lloyd, > > > > One thing to help optimise your code: Guards > > > > isbn_format_valid(ISBN) when length(ISBN) == 10 orelse length(ISBN) == > 13 -> > > [I || I <- ISBN, I < $0 orelse I > $9] == []; > > > > isbn_format_valid(_ISBN) -> > > false. > > > > > > This makes your "is the number equal or between 0 and 9" only be executed > > if the length is 10 or 13. Reason for this, is if user inputs a very > large > > list, you won't have to compare every character only to find later that > > it's not the right length (your machine will take the toll). > > Note that length(ISBN) will be called twice on this maybe very long list, > and that in itself may be bad since length/1 is O(N). > > See my do-it-with-plain-functions safer but more verbose example. > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Tue Sep 20 17:16:30 2016 From: frank.muller.erl@REDACTED (Frank Muller) Date: Tue, 20 Sep 2016 08:16:30 -0700 Subject: [erlang-questions] Distributed OTP app not working when node is "-hidden" Message-ID: Hi everyone I've a simple OTP-compliant release, and I want to make it distributed on two nodes. Following the steps here, it was pretty simple to achieve: http://erlang.org/doc/design_principles/distributed_applications.html as long as my application is not "hidden". My constraint is that I need to keep my node "hidden" because it connects to other critical nodes in our infrastructure. If I set "-hidden" in "vm.args", the distribution breaks and the two nodes (the master and the backup) become both active, which is not desired :-( Anyone knows how to benefit from the distribution feature while keeping my node "hidden"? Any other alternative(s) to solve my issue? Regards Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Sep 20 17:51:37 2016 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 20 Sep 2016 11:51:37 -0400 Subject: [erlang-questions] game engines? In-Reply-To: References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Message-ID: On 9/20/16 10:42 AM, Daniel Goertzen wrote: > Erlang processes shine when they can run asynchronously and in a > loosely coupled manner, so I am skeptical that a process-per-entity > would work well where the entities need to run synchronously (20 > times/sec) and interact heavily. For synchronous, interactive > behavior I suspect the solution you currently have (thread iterating > through objects) is simplest. I'm not actually sure that you'd need to run items synchronously in an actor based design. 1. Anything that's not doing anything can simply suspend itself until an incoming message triggers a state change. That saves a LOT of cycles right there. 2. For things that are moving, I'm not sure how distributing time ticks to x000 processes, and then letting them do their thing, is any different than iterating through the same x000 processes. What gets tricky, in any case, is line-of-sight calculations, and behaviors that are based on what each object sees. That requires some form of global state, and operations on global state. But that's a separate issue, and one that one also has when threading a chain of control through a bunch of objects - either way, one either has to do a global calculation, or each entity has to take a look around itself. > > I remember a discussion years ago about a simulation consisting of > ants randomly moving from square to square on a chess board where only > 1 ant is permitted on a square. The discussion revolved around > process-per-ant and all the synchronization issues that it entailed. > It turned out that flipping things inside out and using a > process-per-*square* and representing the ants as messages passed > between them worked out much better. There are many ways to use > processes, and mapping them to your simulation's actors is not always > best. Is there another way to apply many processes to a military sim? Now isn't that an interesting thought! Miles > > > On Mon, Sep 19, 2016 at 10:55 AM Miles Fidelman > > wrote: > > Thanks to all for your responses. > > Re. a couple of points here, might I ask a few follow-up questions: > > > On 9/18/16 1:37 PM, Lutz Behnke wrote: > >> Hello, >> >> assigning each object in the game gets difficult for a number of >> reasons, when trying to do this for an MMO, especially MMORPGs >> (characterized by a very large number of objects, and active >> entities): >> >> You waste resources (CPU, RAM) when an object is currently not >> being referenced by an active entity (e.g. a client connection, >> thus and avatar or alternatively a Mob/NPC), since there is no >> other process that will send any messages. > > Well yes, but is that not where Erlang shines - being able to > maintain huge numbers of processes (or, in this case, little state > machines)? > > >> >> More importantly, should you scale your engine to multiple hosts, >> you either have to enforce a single process, requiring all >> updates and query messages to be routed to this proc. Or you will >> have to build some master/slave or peer to peer logic, which will >> ensure consistency in the face of CAP. > > I'm actually thinking about military simulation - where the model > is essentially: > > - every simulator (e.g., a flight sim, or a tank) is running on > its own machine, complete with local world model and image > generation (necessary to keep up with jitter-free image generation > during high-g turns - you don't want pilots to puke all over the > simulators) > > - there's a lot of dead reckoning going on locally - the only > things that cross the network are deltas and events, generally > sent by multicast > > - everything is synchronized by GPS time-stamp > > I discovered Erlang when I realized that we (the company I worked > for) took a very different approach for simulating "virtual > forces" (think non-player characters) - when we simulated 1000 > tanks, on one machine, each tank would be an object, and we had 4 > threads winding their way through every object, 20 time a second. > Turns out that the main loops are real spaghetti code that breaks > every time a new property gets added to an object. > > I started wondering why we didn't just have a process per > simulated object - essentially the way we treated the > person-in-the-loop simulators. The answer, of course, being > context switching overhead. > > Then, I discovered Erlang. And I started thinking - why not just > have a process per object. > > >> >> Separating into a) the state of instances, which you can store in >> a KV-store and have b) a pool of generic procs, that will process >> the state with c) a set of modules that provides the logic for a >> particular object allows to push the state to the appropriate >> host. With a separate KV-store that can handle net-partition and >> node failure, you gain even a good amount of fault-resilience. >> >> Please excuse me beating my own drum, but I have implemented a >> prototype of such an engine >> (http://dl.acm.org/citation.cfm?id=2577389&CFID=787355984&CFTOKEN=91169762). >> Unfortunately, for legal reason, I cannot make the code publicly >> available yet. > > Any chance of arranging a copy that's not behind a paywall? > > > Thanks, > > Miles > > >> >> mfg lutz >> >> Am 18.09.2016 um 04:11 schrieb Miles Fidelman: >>> Hi Folks, >>> >>> I'm curious, has anybody written an Erlang-based game engine that >>> implements a process per game entity? >>> >>> I've been been finding various examples of Erlang being used to >>> manage >>> user sessions, and other aspects of MMORPGs - but nothing that >>> simply >>> does the obvious - treating each object, player, etc. as an >>> Erlang process. >>> >>> Am I missing something? >>> >>> Thanks, >>> >>> Miles Fidelman >>> >>> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.nisi@REDACTED Tue Sep 20 18:02:25 2016 From: michael.nisi@REDACTED (Michael Nisi) Date: Tue, 20 Sep 2016 18:02:25 +0200 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> <20160920095906.GB91242@erix.ericsson.se> Message-ID: I just wanted to second Felix really quick. If you're on macOS you should try Dash: https://kapeli.com/dash Having all docs available locally with full text search is priceless. On Tue, Sep 20, 2016 at 4:21 PM, Felix Gallo wrote: > I believe there are similar products for windows, but one that I've found > indispensable for osx is 'Dash', which is a documentation lookup and search > tool that can be configured to pop up at a keystroke. It can include docs > for all the major and most minor programming languages and tools, including > erlang and elixir. It's much faster than browsing around by hand. > > On Sep 20, 2016 2:59 AM, "Raimo Niskanen" ericsson.se> wrote: > >> On Tue, Sep 20, 2016 at 01:48:25AM -0700, Kenneth Lakin wrote: >> > On 09/20/2016 01:20 AM, Roger Lipscombe wrote: >> > > I *do* wish that -- somehow -- the docs could be marked up so that a >> > > Google search would jump directly to the appropriate function. >> > >> > It's a bit more typing (and not at all the same) but >> > >> > http://erlang.org/doc/man/lists.html#flatmap-2 >> >> http://erlang.org/doc/search?q=lists:flatmap >> >> >> -- >> >> / Raimo Niskanen, Erlang/OTP, Ericsson AB >> _______________________________________________ >> 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 alin.popa@REDACTED Tue Sep 20 18:12:44 2016 From: alin.popa@REDACTED (Alin Popa) Date: Tue, 20 Sep 2016 17:12:44 +0100 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> <20160920095906.GB91242@erix.ericsson.se> Message-ID: Oh, wow; I didn't know about Dash; looks amazing, so far; thanks. Alin On Tue, Sep 20, 2016 at 5:02 PM, Michael Nisi wrote: > I just wanted to second Felix really quick. If you're on macOS you should > try Dash: https://kapeli.com/dash > Having all docs available locally with full text search is priceless. > > On Tue, Sep 20, 2016 at 4:21 PM, Felix Gallo wrote: > >> I believe there are similar products for windows, but one that I've found >> indispensable for osx is 'Dash', which is a documentation lookup and search >> tool that can be configured to pop up at a keystroke. It can include docs >> for all the major and most minor programming languages and tools, including >> erlang and elixir. It's much faster than browsing around by hand. >> >> On Sep 20, 2016 2:59 AM, "Raimo Niskanen" > ricsson.se> wrote: >> >>> On Tue, Sep 20, 2016 at 01:48:25AM -0700, Kenneth Lakin wrote: >>> > On 09/20/2016 01:20 AM, Roger Lipscombe wrote: >>> > > I *do* wish that -- somehow -- the docs could be marked up so that a >>> > > Google search would jump directly to the appropriate function. >>> > >>> > It's a bit more typing (and not at all the same) but >>> > >>> > http://erlang.org/doc/man/lists.html#flatmap-2 >>> >>> http://erlang.org/doc/search?q=lists:flatmap >>> >>> >>> -- >>> >>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>> _______________________________________________ >>> 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 felixgallo@REDACTED Tue Sep 20 18:22:15 2016 From: felixgallo@REDACTED (Felix Gallo) Date: Tue, 20 Sep 2016 09:22:15 -0700 Subject: [erlang-questions] game engines? In-Reply-To: References: <740e5ed0-7c20-ec9e-6c1e-8e13e30d9bbc@informatik.haw-hamburg.de> <7df2830a-e6be-0fe3-8516-0cae146a0ba4@meetinghouse.net> Message-ID: I've had decent success with a (non-public) MMO-like game engine using processes in three ways: 1) process per player (user object, connection detail, metadata) 2) process per game entity (location, state) 3) process per region (quadtree or octree populated coordinate) and it all works well with some provisos. The positives I've found so far: 1) Erlang's got great libraries for writing MMO-like systems, out of the box 2) Erlang's scheduler exists, and does a reasonably good job 3) The actor model wins the tradeoff war against all other concurrency models for my use case (and I suspect many/most MMO use cases) 4) Erlang distribution exists, and does a reasonably good job 5) Erlang's deployment story, once you puzzle it out, is pretty great The negatives I've found so far: 1) Out of the box, erlang's shared state is both much larger and much slower than, e.g., your usual bespoke C++ memory slab 2) Straight line computation can be 100x slower than C++ on, e.g., intensive math tasks 3) NIFs that do primarily memory allocation/deallocation can be no faster than native Erlang 4) Erlang's scheduler can still have nontrivial jitter at 99.9pct, but you can write an almost-isochronous scheduler in C++ 5) Navigating through 1-4 above can be problematic in the absence of a highly skilled and experienced team in some use cases 6) It is nontrivial to form that highly skilled and experienced team, even if you have highly skilled and experienced developers open to learning Erlang 7) Much of the popular erlang tooling is buggy, idiosyncratic, and non-orthogonal; picking the right mix is nontrivial Although it is not fully baked yet, and may in fact never be fully baked, I would recommend checking out Pony (http://www.ponylang.org/), which is essentially a well-typed, memory-safe, race-safe Erlang-like minimal C++ with high performance and the actor model. For teams that are coming from C++ and enjoy the affordances of high performance languages but want better equipment and the actor model, that direction might be a more natural fit. On Tue, Sep 20, 2016 at 8:51 AM, Miles Fidelman wrote: > On 9/20/16 10:42 AM, Daniel Goertzen wrote: > > Erlang processes shine when they can run asynchronously and in a loosely > coupled manner, so I am skeptical that a process-per-entity would work well > where the entities need to run synchronously (20 times/sec) and interact > heavily. For synchronous, interactive behavior I suspect the solution you > currently have (thread iterating through objects) is simplest. > > > I'm not actually sure that you'd need to run items synchronously in an > actor based design. > > 1. Anything that's not doing anything can simply suspend itself until an > incoming message triggers a state change. That saves a LOT of cycles right > there. > > 2. For things that are moving, I'm not sure how distributing time ticks to > x000 processes, and then letting them do their thing, is any different than > iterating through the same x000 processes. > > What gets tricky, in any case, is line-of-sight calculations, and > behaviors that are based on what each object sees. That requires some form > of global state, and operations on global state. But that's a separate > issue, and one that one also has when threading a chain of control through > a bunch of objects - either way, one either has to do a global calculation, > or each entity has to take a look around itself. > > > I remember a discussion years ago about a simulation consisting of ants > randomly moving from square to square on a chess board where only 1 ant is > permitted on a square. The discussion revolved around process-per-ant and > all the synchronization issues that it entailed. It turned out that > flipping things inside out and using a process-per-*square* and > representing the ants as messages passed between them worked out much > better. There are many ways to use processes, and mapping them to your > simulation's actors is not always best. Is there another way to apply many > processes to a military sim? > > > Now isn't that an interesting thought! > > Miles > > > > > On Mon, Sep 19, 2016 at 10:55 AM Miles Fidelman < > mfidelman@REDACTED> wrote: > >> Thanks to all for your responses. >> >> Re. a couple of points here, might I ask a few follow-up questions: >> >> >> On 9/18/16 1:37 PM, Lutz Behnke wrote: >> >> Hello, >> >> assigning each object in the game gets difficult for a number of reasons, >> when trying to do this for an MMO, especially MMORPGs (characterized by a >> very large number of objects, and active entities): >> >> You waste resources (CPU, RAM) when an object is currently not being >> referenced by an active entity (e.g. a client connection, thus and avatar >> or alternatively a Mob/NPC), since there is no other process that will send >> any messages. >> >> >> Well yes, but is that not where Erlang shines - being able to maintain >> huge numbers of processes (or, in this case, little state machines)? >> >> >> >> More importantly, should you scale your engine to multiple hosts, you >> either have to enforce a single process, requiring all updates and query >> messages to be routed to this proc. Or you will have to build some >> master/slave or peer to peer logic, which will ensure consistency in the >> face of CAP. >> >> >> I'm actually thinking about military simulation - where the model is >> essentially: >> >> - every simulator (e.g., a flight sim, or a tank) is running on its own >> machine, complete with local world model and image generation (necessary to >> keep up with jitter-free image generation during high-g turns - you don't >> want pilots to puke all over the simulators) >> >> - there's a lot of dead reckoning going on locally - the only things that >> cross the network are deltas and events, generally sent by multicast >> >> - everything is synchronized by GPS time-stamp >> >> I discovered Erlang when I realized that we (the company I worked for) >> took a very different approach for simulating "virtual forces" (think >> non-player characters) - when we simulated 1000 tanks, on one machine, each >> tank would be an object, and we had 4 threads winding their way through >> every object, 20 time a second. Turns out that the main loops are real >> spaghetti code that breaks every time a new property gets added to an >> object. >> >> I started wondering why we didn't just have a process per simulated >> object - essentially the way we treated the person-in-the-loop simulators. >> The answer, of course, being context switching overhead. >> >> Then, I discovered Erlang. And I started thinking - why not just have a >> process per object. >> >> >> >> Separating into a) the state of instances, which you can store in a >> KV-store and have b) a pool of generic procs, that will process the state >> with c) a set of modules that provides the logic for a particular object >> allows to push the state to the appropriate host. With a separate KV-store >> that can handle net-partition and node failure, you gain even a good amount >> of fault-resilience. >> >> Please excuse me beating my own drum, but I have implemented a prototype >> of such an engine (http://dl.acm.org/citation. >> cfm?id=2577389&CFID=787355984&CFTOKEN=91169762). Unfortunately, for >> legal reason, I cannot make the code publicly available yet. >> >> >> Any chance of arranging a copy that's not behind a paywall? >> >> >> Thanks, >> >> Miles >> >> >> >> mfg lutz >> >> Am 18.09.2016 um 04:11 schrieb Miles Fidelman: >> >> Hi Folks, >> >> I'm curious, has anybody written an Erlang-based game engine that >> implements a process per game entity? >> >> I've been been finding various examples of Erlang being used to manage >> user sessions, and other aspects of MMORPGs - but nothing that simply >> does the obvious - treating each object, player, etc. as an Erlang >> process. >> >> Am I missing something? >> >> Thanks, >> >> Miles Fidelman >> >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly@REDACTED Tue Sep 20 18:52:15 2016 From: fly@REDACTED (Fred Youhanaie) Date: Tue, 20 Sep 2016 17:52:15 +0100 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <93d71181-3494-d485-d9d3-c373cca3198d@gmail.com> <20160920095906.GB91242@erix.ericsson.se> Message-ID: A Linux counterpart of Dash is Zeal, https://zealdocs.org/. According to the web site there is an Erlang docset available :) I haven't used it, but a colleague at my previous workplace used it all the time! Cheers, f. On 20/09/16 15:21, Felix Gallo wrote: > I believe there are similar products for windows, but one that I've found indispensable for osx is 'Dash', which is a documentation lookup and search tool that can be configured to pop up at a > keystroke. It can include docs for all the major and most minor programming languages and tools, including erlang and elixir. It's much faster than browsing around by hand. > > > On Sep 20, 2016 2:59 AM, "Raimo Niskanen" > wrote: > > On Tue, Sep 20, 2016 at 01:48:25AM -0700, Kenneth Lakin wrote: > > On 09/20/2016 01:20 AM, Roger Lipscombe wrote: > > > I *do* wish that -- somehow -- the docs could be marked up so that a > > > Google search would jump directly to the appropriate function. > > > > It's a bit more typing (and not at all the same) but > > > > http://erlang.org/doc/man/lists.html#flatmap-2 > > http://erlang.org/doc/search?q=lists:flatmap > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > 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 lloyd@REDACTED Tue Sep 20 18:52:18 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 20 Sep 2016 12:52:18 -0400 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: I'm soaking it all in. Question: how can we time the proposed solutions to compare performance? Thanks to all, Lloyd Sent from my iPad On Sep 20, 2016, at 11:14 AM, Pagayon, Ruel wrote: >> Note that length(ISBN) will be called twice on this maybe very long list, >> and that in itself may be bad since length/1 is O(N). >> >> See my do-it-with-plain-functions safer but more verbose example. > > Thanks for clearing that up! That definitely is a better way. > > Cheers, > Ruel > > Ruel Pagayon - ruel@REDACTED > Platform Engineer > Networking and Communications > >> On Tue, Sep 20, 2016 at 11:00 PM, Raimo Niskanen wrote: >> On Tue, Sep 20, 2016 at 10:17:36PM +0800, Pagayon, Ruel wrote: >> > Hello Lloyd, >> > >> > One thing to help optimise your code: Guards >> > >> > isbn_format_valid(ISBN) when length(ISBN) == 10 orelse length(ISBN) == 13 -> >> > [I || I <- ISBN, I < $0 orelse I > $9] == []; >> > >> > isbn_format_valid(_ISBN) -> >> > false. >> > >> > >> > This makes your "is the number equal or between 0 and 9" only be executed >> > if the length is 10 or 13. Reason for this, is if user inputs a very large >> > list, you won't have to compare every character only to find later that >> > it's not the right length (your machine will take the toll). >> >> Note that length(ISBN) will be called twice on this maybe very long list, >> and that in itself may be bad since length/1 is O(N). >> >> See my do-it-with-plain-functions safer but more verbose example. >> >> -- >> >> / Raimo Niskanen, Erlang/OTP, Ericsson AB >> _______________________________________________ >> 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 eric.pailleau@REDACTED Tue Sep 20 18:53:19 2016 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Tue, 20 Sep 2016 18:53:19 +0200 Subject: [erlang-questions] Erlang documentation In-Reply-To: <57E0FB9C.4080405@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <57E0FB9C.4080405@gmail.com> Message-ID: <080uofog0bjf3jjes5m8smqk.1474390399527@email.android.com> Hi, I agree, there is no information on which version a module or a function is introduced or removed. Sorry to give a personal project myself, But 'geas' plugins tells you on which version a beam or a souce can run, on a whole project https://github.com/crownedgrouse/geas Hope this can help many "Envoy? depuis mon mobile " Eric ---- Michael Truog a ?crit ---- >On 09/20/2016 01:53 AM, Alin Popa wrote: >> Worth mentioning that maybe there should be a version tag for each function/module saying when it was added? Happened to me few times already to realise that a particular function which was present in the documentation, was not available in my particular Erlang version, and I found out that only when running the tests (e.g. ets:update_counter/4 is not available in Erlang 17, but I can see it in here http://erlang.org/doc/man/ets.html#update_counter-4; and unless I'm missing something, it doesn't say when it was added). >Currently, we can use the external site http://erldocs.com/18.3/stdlib/ets.html?i=352 and change the version number in the URL to determine that the change occurred sometime in an 18.x release, but it would be nice to make things simpler. I have seen this be a problem more than once. > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael@REDACTED Tue Sep 20 19:29:34 2016 From: michael@REDACTED (Michael Terry) Date: Tue, 20 Sep 2016 10:29:34 -0700 Subject: [erlang-questions] httpc:request fails on some sites Message-ID: Hi there, Does anyone here know the likely reason the last line is failing? ~$ curl https://api.datamarket.azure.com Object moved

Object moved to here.

~$ erl Erlang/OTP 19 [erts-8.0.2] [source-753b9b9] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V8.0.2 (abort with ^G) 1> inets:start(). ok 2> ssl:start(). ok 3> httpc:request("https://www.google.com"). {ok,{{"HTTP/1.1",200,"OK"}, ...truncated... 4> httpc:request("https://api.datamarket.azure.com"). {error,{failed_connect,[{to_address,{"api.datamarket.azure.com", 443}}, {inet,[inet],closed}]}} https://gist.github.com/formido/db472011f2dd3f47a99b66bd8784ee55 Cheers, Mike From ilya.khaprov@REDACTED Tue Sep 20 19:41:55 2016 From: ilya.khaprov@REDACTED (Ilya Khaprov) Date: Tue, 20 Sep 2016 17:41:55 +0000 Subject: [erlang-questions] httpc:request fails on some sites In-Reply-To: References: Message-ID: Hi Michael, You can force TLS version here: httpc:request(get, {"https://api.datamarket.azure.com", []}, [{ssl, [{versions, ['tlsv1']}]}, {autoredirect, false}], []). Ilya > From: michael@REDACTED > Date: Tue, 20 Sep 2016 10:29:34 -0700 > To: erlang-questions@REDACTED > Subject: [erlang-questions] httpc:request fails on some sites > > Hi there, > > Does anyone here know the likely reason the last line is failing? > > ~$ curl https://api.datamarket.azure.com > Object moved >

Object moved to here.

> > ~$ erl > Erlang/OTP 19 [erts-8.0.2] [source-753b9b9] [64-bit] [smp:2:2] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V8.0.2 (abort with ^G) > 1> inets:start(). > ok > 2> ssl:start(). > ok > 3> httpc:request("https://www.google.com"). > {ok,{{"HTTP/1.1",200,"OK"}, ...truncated... > 4> httpc:request("https://api.datamarket.azure.com"). > {error,{failed_connect,[{to_address,{"api.datamarket.azure.com", > 443}}, > {inet,[inet],closed}]}} > > https://gist.github.com/formido/db472011f2dd3f47a99b66bd8784ee55 > > Cheers, > Mike > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael@REDACTED Tue Sep 20 19:47:23 2016 From: michael@REDACTED (Michael Terry) Date: Tue, 20 Sep 2016 10:47:23 -0700 Subject: [erlang-questions] httpc:request fails on some sites In-Reply-To: References: Message-ID: Thank you, my friend. On Tue, Sep 20, 2016 at 10:41 AM, Ilya Khaprov wrote: > Hi Michael, > > You can force TLS version here: > > httpc:request(get, {"https://api.datamarket.azure.com", []}, [{ssl, > [{versions, ['tlsv1']}]}, {autoredirect, false}], []). > > Ilya > >> From: michael@REDACTED >> Date: Tue, 20 Sep 2016 10:29:34 -0700 >> To: erlang-questions@REDACTED >> Subject: [erlang-questions] httpc:request fails on some sites > >> >> Hi there, >> >> Does anyone here know the likely reason the last line is failing? >> >> ~$ curl https://api.datamarket.azure.com >> Object moved >>

Object moved to here.

>> >> ~$ erl >> Erlang/OTP 19 [erts-8.0.2] [source-753b9b9] [64-bit] [smp:2:2] >> [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V8.0.2 (abort with ^G) >> 1> inets:start(). >> ok >> 2> ssl:start(). >> ok >> 3> httpc:request("https://www.google.com"). >> {ok,{{"HTTP/1.1",200,"OK"}, ...truncated... >> 4> httpc:request("https://api.datamarket.azure.com"). >> {error,{failed_connect,[{to_address,{"api.datamarket.azure.com", >> 443}}, >> {inet,[inet],closed}]}} >> >> https://gist.github.com/formido/db472011f2dd3f47a99b66bd8784ee55 >> >> Cheers, >> Mike >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Tue Sep 20 21:55:16 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 20 Sep 2016 21:55:16 +0200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: On Tue, Sep 20, 2016 at 6:52 PM, Lloyd R. Prentice wrote: > Question: how can we time the proposed solutions to compare performance? One solution is https://github.com/jlouis/eministat But one has to weigh the most efficient solution against two things: * Which solution is the most readable and elegant. It is more likely to be correct. * How many ISBN numbers per second are we looking at? Modern computers are unfairly quick at computation once data are on the CPU itself. So unless you have a very large count of ISBN numbers to verify, I would perhaps spend my time elsewhere in the code base. Your systems overall efficiency is likely to suffer from other factors than a single ISBN verification. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Sep 20 22:34:38 2016 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 20 Sep 2016 22:34:38 +0200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: On Tue, Sep 20, 2016 at 9:55 PM, Jesper Louis Andersen wrote: > > On Tue, Sep 20, 2016 at 6:52 PM, Lloyd R. Prentice > wrote: >> >> Question: how can we time the proposed solutions to compare performance? > > > One solution is https://github.com/jlouis/eministat > > But one has to weigh the most efficient solution against two things: > > * Which solution is the most readable and elegant. It is more likely to be > correct. > * How many ISBN numbers per second are we looking at? > > Modern computers are unfairly quick at computation once data are on the CPU > itself. So unless you have a very large count of ISBN numbers to verify, I > would perhaps spend my time elsewhere in the code base. Your systems overall > efficiency is likely to suffer from other factors than a single ISBN > verification. Agreed - if you think about it, the ISBN number must have come from *somewhere* - if they have come from disk then at a guess most of the time will be spent reading and parsing the input. If they come from a database most of the time will be in format conversions. Once the ISBN is in RAM then any processing involved will be fast. Modern processors do Giga instructions/second so converting millions of ISBN/second should not be a problem - reading and *parsing* millions of numbers per second would be a problem) The 'old truth' was that most time in most applications was spent in I/O not in computation (apart from computational heavy problems) The problem with comparing different versions of the routine isbn_format_valid that you don't see the big picture. If isbn_format_valid only takes 1% if the total time then it doesn't matter if you optimize it. The old advice was write as clearly as possible, measure, then optimize the least efficient part *if necessary*. In my experience optimization is hardly ever needed - of all the code I've ever written only a tiny fraction ever really needed optimizing. By optimization I mean choosing complex code that is fast, rather than simple code that is easy to understand. Choosing a smart algorithm that is intrinsically efficient is not something that I consider to be an optimisation but rather good design. The advice - "write first - then measure" is difficult to follow since measurements are difficult to make and interpret. The only thing I know is that my intuition as to where the time really goes is almost always wrong (apart from in I/O which is always slow) /Joe > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From trenthampton@REDACTED Tue Sep 20 20:47:42 2016 From: trenthampton@REDACTED (Trent Hampton) Date: Tue, 20 Sep 2016 12:47:42 -0600 Subject: [erlang-questions] Erlang cookies, rpc, security, mnesia, hidden nodes, VPN tunnels and stuff! Message-ID: Greetings Erlang Wizards! I have a client server erlang application where each server is connected to every other and is running an instance of an mnesia database across point to point VPN tunnels. I would like to be able to use erlang rpc on the clients to make function calls on the servers without exposing raw access to the mnesia database. That is, I do not want to expose, to the clients, the cookie that I use to connect mnesia nodes together. Is it possible to have the servers and mnesia communicate using one cookie but have the clients connect to the servers using another cookie so that the clients cannot gain access to the raw database and so that there are no transitive connections? According to http://erlang.org/doc/reference_manual/distributed.html section 13.3-5; it is possible to turn off transitive connections with the -connect_all false flag or by making a node hidden. Is it possible to use the hidden node and also use a different cookie for the client to server connection than the cookie used between the servers? Thank you! Trent From lloyd@REDACTED Wed Sep 21 00:43:13 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 20 Sep 2016 18:43:13 -0400 (EDT) Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: <1474411393.19579594@apps.rackspace.com> Thanks Joe and Jesper. In my case the ISBN numbers come as callback (if I'm using the right term) from an HTML form. Thus they are by nature untrustworthy. It would be much better to catch format errors before I submit them on to a book info api. I do understand that in the scheme of things ISBN validation will have little to no influence on user experience or the performance the system as a whole. You guys have taught me well that premature optimization is wasted effort. To confess, I was fishing to learn and, perhaps, help others learn a new skill. Given that folks have proposed several algorithmic solutions to the same problem, it seemed like a teachable opportunity to learn how to compare execution time of the respective solutions. Someday I may need to know how to do this for real. I do hope I'm not imposing too much on list readers. But it does seem to me like a worthwhile exercise. Thanks again, Lloyd -----Original Message----- From: "Joe Armstrong" Sent: Tuesday, September 20, 2016 4:34pm To: "Jesper Louis Andersen" Cc: "Lloyd R. Prentice" , "Erlang" Subject: Re: [erlang-questions] List comprehension puzzler On Tue, Sep 20, 2016 at 9:55 PM, Jesper Louis Andersen wrote: > > On Tue, Sep 20, 2016 at 6:52 PM, Lloyd R. Prentice > wrote: >> >> Question: how can we time the proposed solutions to compare performance? > > > One solution is https://github.com/jlouis/eministat > > But one has to weigh the most efficient solution against two things: > > * Which solution is the most readable and elegant. It is more likely to be > correct. > * How many ISBN numbers per second are we looking at? > > Modern computers are unfairly quick at computation once data are on the CPU > itself. So unless you have a very large count of ISBN numbers to verify, I > would perhaps spend my time elsewhere in the code base. Your systems overall > efficiency is likely to suffer from other factors than a single ISBN > verification. Agreed - if you think about it, the ISBN number must have come from *somewhere* - if they have come from disk then at a guess most of the time will be spent reading and parsing the input. If they come from a database most of the time will be in format conversions. Once the ISBN is in RAM then any processing involved will be fast. Modern processors do Giga instructions/second so converting millions of ISBN/second should not be a problem - reading and *parsing* millions of numbers per second would be a problem) The 'old truth' was that most time in most applications was spent in I/O not in computation (apart from computational heavy problems) The problem with comparing different versions of the routine isbn_format_valid that you don't see the big picture. If isbn_format_valid only takes 1% if the total time then it doesn't matter if you optimize it. The old advice was write as clearly as possible, measure, then optimize the least efficient part *if necessary*. In my experience optimization is hardly ever needed - of all the code I've ever written only a tiny fraction ever really needed optimizing. By optimization I mean choosing complex code that is fast, rather than simple code that is easy to understand. Choosing a smart algorithm that is intrinsically efficient is not something that I consider to be an optimisation but rather good design. The advice - "write first - then measure" is difficult to follow since measurements are difficult to make and interpret. The only thing I know is that my intuition as to where the time really goes is almost always wrong (apart from in I/O which is always slow) /Joe > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From kennethlakin@REDACTED Wed Sep 21 00:53:55 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Tue, 20 Sep 2016 15:53:55 -0700 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <20160920150018.GB3154@erix.ericsson.se> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: <18d389f6-e74b-a28e-50b2-36f0ff2a5e3f@gmail.com> On 09/20/2016 08:00 AM, Raimo Niskanen wrote: > Note that length(ISBN) will be called twice on this maybe very long list, > and that in itself may be bad since length/1 is O(N). That seems easy enough to fix: when length(I) =< 13 andalso (length(I) == 10 orelse length(I) == 13) The assembler output indicates that length is -potentially- called three times in this example. I guess the Erlang compiler isn't smart enough to recognize and remove the redundant calls. OTOH, I would guess that the perf gain for the typical Erlang program isn't worth the additional complication in the compiler code. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ok@REDACTED Wed Sep 21 02:22:17 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 21 Sep 2016 12:22:17 +1200 Subject: [erlang-questions] Learning from the Manual In-Reply-To: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> References: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> Message-ID: <5819ad0b-f509-d56f-0dda-d566f9204ba7@cs.otago.ac.nz> On 20/09/16 6:34 PM, Peter J Etheridge wrote: > Dear List, > I assume the Manual is clear to those who understand it. I've been reading programming language manuals since oh, 1974. The first thing to say is that there are traditionally three quite separate books: - Language Reference Manual (Overview, lexical structure, syntax, pragmatics, core library). For a rather bloated example of this, see the Java definition. - User's Guide How to use the compiler, linker, debugger; how to interface to data bases, other languages, networks. - Books for beginners, generally written by 3rd parties. and there will also be - Documentation for major libraries. And by the way, it really really helps if these things are available on paper or in PDF form so that you don't have to go clickety clickety OH MY CARPAL TUNNEL to get from one paragraph to the next. Especially with PDF or single-page HTML it is really nice to search for things that the authors didn't think to index or link. I did not say ONLY available in such forms. If you look at the Learn You Some Erlang for Great Good! web site you'll notice additional material (like the stuff about maps and time measurement) in the on-line version. LYSE not being the Nugganite scriptures (from Pratchett's "Monstrous Regiment"), new material doesn't magically turn up in paper copies. Any rate, the *point* is that from that long experience of reading language reference manuals, I expect that *I* will be able to learn a language from its reference manual, but that most others will find it hard. *Learning* Erlang is best done from the Erlang books listed on the documentation page. The r?le of the reference manual is to let you look up the details. This is why it is so important to have it as a single file you can search. And it is important that all the details should be there. (For example, I am not happy that the Erlang Reference Manual does not include a formal grammar.) In the case of programming languages, ANSI used to have a practice of supplying separate "Standard" (WHAT) and "Rationale" (WHY) material. The C89 rationale is still worth reading. ISO defenestrated that. All in all, I don't think the documentation is in *terrible* shape. I've seen worse. Hmm. I have to get the next draft of a paper ready. I was supposed to get it done last week (sigh). When I've done that, I might try my hand at writing a chapter of an Erlang Reference Manual (NRSV) and put it up for comments. From ok@REDACTED Wed Sep 21 02:44:59 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 21 Sep 2016 12:44:59 +1200 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> Message-ID: <7beedb94-47aa-dcf0-a689-b00b65b3df25@cs.otago.ac.nz> I must say that the elixir/Application.html page looks ugly to me. Typographically, the main text font and the typewriter font that I'm seeing do not fit together (they have different x-heights). The syntax colouring doesn't make sense to me: some function names are in green, some are not. Some things are in orange, and I haven't a clue why. The main effect is to make some things I need to see wash out (pale purple against white). The page is 12 clicks high, and there are no internal navigation aids. Well, I tell a lie. If you see a vertical purple bar on the left and click on that, it will move to the top of the window. That is, you *can* navigate to something you are *already at*. There's a lot more vertical space than I like. Look at "Types", for example. This is another example where clicking on something you are already at, like the purple "value", takes you where you already are, not to something handy like a list of functions that accept or return that type. If you are going to change font size a lot (and "Callbacks", "start(start_type, start_args)", and "Specs", three successive lines, are in three different sizes) the thing that needs to be in a large plain font is the thing you are looking for, which is the thing you are defining. "Specs" is just noise, better not there. What needs to be highlighted is "start(start_type, start_args)". In contrast, with the design_principles/applications.html page, there's a high density of useful information per window, and BOOM the top of the page tells me just what I need to know. There is useful internal navigation. The fonts don't quite fit together, but it's less obtrusive than the Elixir page. Altogether I'm a much happier reader with this page. The one thing that would improve > http://erlang.org/doc/man/application.html for me would be if there was a table with the functions listed in functional (topical) groups, as well as the alphabetic list. (See "Smalltalk 4-pane browser".) This applies to paper/PDF as well as HTML. From ok@REDACTED Wed Sep 21 03:12:54 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 21 Sep 2016 13:12:54 +1200 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> Message-ID: <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> On 20/09/16 8:20 PM, Roger Lipscombe wrote: > I *do* wish that -- somehow -- the docs could be marked up so that a > Google search would jump directly to the appropriate function. Can you point us to documentation for some other project where this works? If I search for "Java String split" Google offers - a Stack Overflow question >> the top of the java.lang.String page for Java 1.7 - something from Tutorialspoint - something from Mkyong.com - two pages from JavaDevNotes.com ... all of which are on topic, but for none of which does it take me anywhere but the top of the page. Similarly, searching for "Haskell Data.List reverse" takes me to the top of the Data.List.html page, not to the reverse function. (It's a pity that we're still getting the 1.7 link instead of a 1.8 link; that's why I keep a copy of the 1.8 docs on my laptop.) "erlang lists flatmap" takes you to the top of the lists.html page, true. When you get there, the navbar on the left shows an alphabetic list of functions, and flatmap/2 is about half way down that list, so it's one more click to get there. This is as good as I've seen for any other language. From jose.valim@REDACTED Wed Sep 21 03:35:59 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 21 Sep 2016 03:35:59 +0200 Subject: [erlang-questions] Apology In-Reply-To: <7beedb94-47aa-dcf0-a689-b00b65b3df25@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <7beedb94-47aa-dcf0-a689-b00b65b3df25@cs.otago.ac.nz> Message-ID: > > The syntax colouring doesn't make sense to me: > some function names are in green, some are not. > Some things are in orange, and I haven't a clue why. > Unfortunately syntax highlighting is done in JavaScript with an Elixir lexer implemented in JavaScript. In other words: I also have no idea why some things are in orange (I never had the courage to investigate). That is, you *can* navigate to something you are *already at*. > The main reason for this is to be able to click on the function name and change the browser URL so you can copy, paste it and send it to someone. That's similar to the headers in a README on Github . Otherwise, your only option would be to go to the sidebar, find the function again and then copy the link. For exploring the current page as a whole, the sidebar was meant to be the place to go. From there you can go to the top of the page, navigate to the Summary, as well as list and navigate to each Function, Type and Callback. "Specs" is just noise, better not there. > I like this suggestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Sep 21 03:48:04 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 21 Sep 2016 13:48:04 +1200 Subject: [erlang-questions] Learning from the Manual In-Reply-To: <20160920101840.otsbzrmkzidkvzcn@corelatus.se> References: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> <20160920101840.otsbzrmkzidkvzcn@corelatus.se> Message-ID: On 20/09/16 10:18 PM, Matthias Lang wrote: > http://learnyousomeerlang.com/content > > I took a look at his "datatype" section to see how he dealt with the > "there aren't actually any strings" problem. And it turns out there is > no string section! Perfect. The *paper* version has "strings" in the index, with - as binaries - a lists - to a number as subtopics. There's a great Open Source information retrieval engine that can be used to power documentation searches. It's called ATIRE, it has virtues too numerous to list here, and it's free at http://atire.org/index.php?title=Main_Page (The documentation could be better. You get what you pay for.) From ok@REDACTED Wed Sep 21 04:51:38 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 21 Sep 2016 14:51:38 +1200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <1474379070.78336567@apps.rackspace.com> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> Message-ID: On 21/09/16 1:44 AM, lloyd@REDACTED wrote: > ISBNS are either 10 or 13-digits. The standard specifies a check-sum algorithm, but that seemed too complicated for my purposes. So, after struggling with the list comprehension puzzler and Dan Gudmundsson's helpful input, I came up with this: > > isbn_format_valid(ISBN) -> > D = fun(I) -> (I >= $0) and (I =< 9) end, > NotIntegers = [I || I <- ISBN, D(I) == true], > Flag1 = NotIntegers == [], > Flag2 = (length(ISBN) == 13) or (length(ISBN) == 10), > Flag1 and Flag2. I find this confusing. First off, 10-digit ISBNs have four parts and 13-digit ones five. - GS1 prefix, - registration group element, - registrant element - publication element, - check digit. These things are commonly written separated by spaces or hyphens, e.g., "978-1-59327-435-1" is a valid ISBN. (That of LYSE, in fact.) No, the definition says "The elements MUST .. be separated clearly by hyphens or spaces when displayed in human readable form." So we probably want to start by stripping out spaces and hyphens: [Space, Hyphen] = " -", Stripped = [C || C <- ISBN, C =/= Space, C =/= Hyphen], or else document that this has already been done. Strictly speaking, we'd need to check that the parts are valid, and there's a file we could download from https://www.isbn-international.org/range_file_generation but that goes further than anyone but a specialist would need. Second, all of the elements of a string are necessarily integers, or it wouldn't _be_ a string. So "NotIntegers" is very confusing. NonDigits = [C || C <- Stripped, C < $0 orelse C > $9], Third, this isn't actually right either. The check digit may be an X. You don't want to reject a valid ISBN because it has an X at the end. Maybe you don't want to accept 10-digit ISBNs, but again, that should be documented. We end up with the following code (which has had some very limited testing): % isbn_is_valid(String) % is true when, after stripping out spaces and hyphens that % are required for human-readable display, String is a 10- % or 13-digit ISBN with a valid checksum (and a valid GS1 % prefix if it's a 13-digit ISBN). This assumes that the % argument is a string (character code list). -spec isbn_is_valid(ISBN :: string()) -> boolean(). isbn_is_valid(ISBN) -> isbn_checksum_ok(stripped_isbn(ISBN)). % stripped_isbn(String) % returns String without any hyphens or spaces. % It does not check that the separators are in sensible % places because most of the fields are variable in size. -spec stripped_isbn(ISBN :: string()) -> string(). stripped_isbn(ISBN) -> [Space, Hyphen] = " -", [C || C <- ISBN, C =/= Space, C =/= Hyphen]. -define(isdigit(X), ($0 =< X andalso X =< $9)). % isbn_checksum_ok(ISBN) reports whether a string % not containing hyphens or spaces is a valid 10-digit % or 13-digit ISBN, validity defined as valid checksum % and valid GS1 field, if any. The other fields are % not checked for validity; that would need a data base % lookup. -spec isbn_checksum_ok(ISBN :: string()) -> boolean(). isbn_checksum_ok([A,B,C,D,E,F,G,H,I,J]) % 10-digit when ?isdigit(A), ?isdigit(B), ?isdigit(C), ?isdigit(D), ?isdigit(E), ?isdigit(F), ?isdigit(G), ?isdigit(H), ?isdigit(I), ( J =:= $X orelse ?isdigit(J) ) -> ( (A - $0) * 10 + (B - $0) * 9 + (C - $0) * 8 + (D - $0) * 7 + (E - $0) * 6 + (F - $0) * 5 + (G - $0) * 4 + (H - $0) * 3 + (I - $0) * 2 + (if J =:= $X -> 10 ; true -> J - $0 end) ) rem 11 =:= 0; isbn_checksum_ok([A,B,C,D,E,F,G,H,I,J,K,L,M]) % 13-digit when A =:= $9, B =:= $7, $8 =< C, C =< $9, ?isdigit(D), ?isdigit(E), ?isdigit(F), ?isdigit(G), ?isdigit(H), ?isdigit(I), ?isdigit(J), ?isdigit(K), ?isdigit(L), ?isdigit(M) -> ( ( (A-$0) + (C-$0) + (E-$0) + (G-$0) + (I-$0) + (K-$0) + (M-$0) ) + ( (B-$0) + (D-$0) + (F-$0) + (H-$0) + (J-$0) + (L-$0) ) * 3 ) rem 10 =:= 0; isbn_checksum_ok(_) -> false. The 13-digit checksum code has been tweaked to recognise the fact that according to the 2012 Sixth edition of the ISBN User's Manual, which is still current, the only valid GS1 prefixes are 978 and 979. I repeat: this has had some but very limited testing. It's free and worth every penny. From ok@REDACTED Wed Sep 21 05:08:05 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 21 Sep 2016 15:08:05 +1200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <1474411393.19579594@apps.rackspace.com> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> <1474411393.19579594@apps.rackspace.com> Message-ID: <2164eecc-8671-be17-b61a-bf6d8ccff0c7@cs.otago.ac.nz> On 21/09/16 10:43 AM, lloyd@REDACTED wrote: > Thanks Joe and Jesper. > > In my case the ISBN numbers come as callback (if I'm using the right term) >from an HTML form. It's hard to believe I'm saying this, but if the HTML form is under your control, why not validate the ISBNs with JavaScript code in the form? You could use regular expressions like /^[0-9]([- ]?[0-9]){8}[- ]?([0-9X]|[0-9]([- ]?[0-9]){3})$/ to check their format and there are quite a few ISBN checksum validators for JavaScript out there on the web. That way the user gets immediate feedback. Let's face it, this is one of the jobs JavaScript-in-the-browser was designed to do. > I do understand that in the scheme of things ISBN validation will have little to no influence on user experience or the performance the system as a whole. Doing it in the client will definitely have an influence on user experience: a positive one. As for system performance, a failed check in the browser saves a round trip to the server. From ok@REDACTED Wed Sep 21 05:53:17 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 21 Sep 2016 15:53:17 +1200 Subject: [erlang-questions] Apology In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <7beedb94-47aa-dcf0-a689-b00b65b3df25@cs.otago.ac.nz> Message-ID: <157513c8-a324-beae-8c9b-71410af8a51b@cs.otago.ac.nz> On 21/09/16 1:35 PM, Jos? Valim wrote: >> > The main reason for this is to be able to click on the function name and > change the browser URL so you can copy, paste it and send it to someone. Oh that's clever. It never occurred to me that that was the point. It's not something I'm going to do very often, mind. I wrote a lot about why it wasn't obvious that you *could* get functions in the navbar, but I don't want to waste any more of anyone's time. From trapexit@REDACTED Tue Sep 20 23:25:04 2016 From: trapexit@REDACTED (Antonio SJ Musumeci) Date: Tue, 20 Sep 2016 17:25:04 -0400 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: "Choosing a smart algorithm that is intrinsically efficient is not something that I consider to be an optimisation but rather good design." -Joe This can not be pointed out enough. A significant number of slow systems in my experience are due to authors not properly understanding or recognizing the costs, in memory and cpu, of the functions and data structures they use. My example was less about speed and more about understanding that 2 * O(n) on an unbounded list is dangerous and there are reasonably simple ways to handle the situation that are arguably easier to read, clearly faster, and have upperbounds on costs. That original function should hopefully stick out as a possibly dangerous and costly design in almost an instinctive way. To take my paranoia regarding such things further... in a situation like this, depending on the source of the data, it may be better to not use lists. Maybe tuples. Or carry the length around separately if originally stored in a way where it was already calculated. And it's not just for speed but not throwing away information unnecessarily. Not making assumptions about how the data will be used such that getting that information back later could be costly. In this case it's very similar to char* strings in C. Often the length is known at some point but almost always thrown away leading to many functions needing to recalculate it. On Tue, Sep 20, 2016 at 4:34 PM, Joe Armstrong wrote: > On Tue, Sep 20, 2016 at 9:55 PM, Jesper Louis Andersen > wrote: > > > > On Tue, Sep 20, 2016 at 6:52 PM, Lloyd R. Prentice < > lloyd@REDACTED> > > wrote: > >> > >> Question: how can we time the proposed solutions to compare performance? > > > > > > One solution is https://github.com/jlouis/eministat > > > > But one has to weigh the most efficient solution against two things: > > > > * Which solution is the most readable and elegant. It is more likely to > be > > correct. > > * How many ISBN numbers per second are we looking at? > > > > Modern computers are unfairly quick at computation once data are on the > CPU > > itself. So unless you have a very large count of ISBN numbers to verify, > I > > would perhaps spend my time elsewhere in the code base. Your systems > overall > > efficiency is likely to suffer from other factors than a single ISBN > > verification. > > Agreed - if you think about it, the ISBN number must have come from > *somewhere* - if they have come from disk then at a guess > most of the time will be spent reading and parsing the input. If they come > from a database most of the time will be in format conversions. > > Once the ISBN is in RAM then any processing involved will be fast. > Modern processors do Giga instructions/second so converting > millions of ISBN/second should not be a problem - reading and *parsing* > millions of numbers per second would be a problem) > > The 'old truth' was that most time in most applications was spent in I/O > not in computation (apart from computational heavy problems) > > The problem with comparing different versions of the routine > isbn_format_valid that you don't see the big picture. If isbn_format_valid > only takes 1% if the total time then it doesn't matter if you > optimize it. > > The old advice was write as clearly as possible, measure, then > optimize the least efficient part *if necessary*. > > In my experience optimization is hardly ever needed - of all the code I've > ever written only a tiny fraction ever really needed optimizing. > > By optimization I mean choosing complex code that is fast, rather than > simple > code that is easy to understand. Choosing a smart algorithm that is > intrinsically efficient is not something that I consider to be an > optimisation > but rather good design. > > The advice - "write first - then measure" is difficult to follow since > measurements are difficult to make and interpret. The only thing I > know is > that my intuition as to where the time really goes is almost always > wrong (apart from in I/O which is always slow) > > /Joe > > > > > > > -- > > J. > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Wed Sep 21 08:02:50 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Tue, 20 Sep 2016 23:02:50 -0700 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <2164eecc-8671-be17-b61a-bf6d8ccff0c7@cs.otago.ac.nz> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> <1474411393.19579594@apps.rackspace.com> <2164eecc-8671-be17-b61a-bf6d8ccff0c7@cs.otago.ac.nz> Message-ID: <828cc39a-b5e6-a3f0-7763-e46a3c9b26d0@gmail.com> On 09/20/2016 08:08 PM, Richard A. O'Keefe wrote: > It's hard to believe I'm saying this, but if the HTML form is under > your control, why not validate the ISBNs with JavaScript code in the > form? It's a nice way to avoid a roundtrip to signal data entry errors, but if the data is important, you'd have to check it again on the server side anyway. The client can always lie (or malfunction), so you can't trust what they've sent. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From raimo+erlang-questions@REDACTED Wed Sep 21 08:30:33 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 21 Sep 2016 08:30:33 +0200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <18d389f6-e74b-a28e-50b2-36f0ff2a5e3f@gmail.com> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> <18d389f6-e74b-a28e-50b2-36f0ff2a5e3f@gmail.com> Message-ID: <20160921063033.GC3154@erix.ericsson.se> On Tue, Sep 20, 2016 at 03:53:55PM -0700, Kenneth Lakin wrote: > On 09/20/2016 08:00 AM, Raimo Niskanen wrote: > > Note that length(ISBN) will be called twice on this maybe very long list, > > and that in itself may be bad since length/1 is O(N). > > That seems easy enough to fix: > > when length(I) =< 13 andalso (length(I) == 10 orelse length(I) == 13) Sorry about being unclear. I should have written "... *called* (twice) ..." since there is little greater harm in calling it twice than calling it once. It is still O(N) if you call it a constant number of times, and the subsequent times it is likely that data is in the processor's cache so they may be faster. The harm is in calling length/1 even once on a possibly very long list. We have had a suggestion to add a guard length(List, Max) or max_length(List, Max) that would stop traversal after Max elements. This would be O(min(length(List), Max)), which is O(Max), which for a constant Max is O(1). But we never got to it... -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From Tobias.Schlager@REDACTED Wed Sep 21 09:20:54 2016 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Wed, 21 Sep 2016 07:20:54 +0000 Subject: [erlang-questions] Erlang cookies, rpc, security, mnesia, hidden nodes, VPN tunnels and stuff! Message-ID: <12F2115FD1CCEE4294943B2608A18FA301C28741C2@MAIL01.win.lbaum.eu> Hi Trent, AFAIK it is possible to use different cookies for different nodes, the distribution protocol allows it. Furthermore it is possible to set different cookies on a node for remote nodes manually, see [1]. However, most probably this is not a good idea and I have to admit that I've never used this 'feature' (in production). Regards Tobias [1] http://erlang.org/doc/man/erlang.html#set_cookie-2 ________________________________________ Von: erlang-questions-bounces@REDACTED [erlang-questions-bounces@REDACTED]" im Auftrag von "Trent Hampton [trenthampton@REDACTED] Gesendet: Dienstag, 20. September 2016 20:47 An: erlang-questions@REDACTED Betreff: [erlang-questions] Erlang cookies, rpc, security, mnesia, hidden nodes, VPN tunnels and stuff! Greetings Erlang Wizards! I have a client server erlang application where each server is connected to every other and is running an instance of an mnesia database across point to point VPN tunnels. I would like to be able to use erlang rpc on the clients to make function calls on the servers without exposing raw access to the mnesia database. That is, I do not want to expose, to the clients, the cookie that I use to connect mnesia nodes together. Is it possible to have the servers and mnesia communicate using one cookie but have the clients connect to the servers using another cookie so that the clients cannot gain access to the raw database and so that there are no transitive connections? According to http://erlang.org/doc/reference_manual/distributed.html section 13.3-5; it is possible to turn off transitive connections with the -connect_all false flag or by making a node hidden. Is it possible to use the hidden node and also use a different cookie for the client to server connection than the cookie used between the servers? Thank you! Trent _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From pierrefenoll@REDACTED Wed Sep 21 09:23:58 2016 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Wed, 21 Sep 2016 09:23:58 +0200 Subject: [erlang-questions] Erlang documentation In-Reply-To: <080uofog0bjf3jjes5m8smqk.1474390399527@email.android.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <57E0FB9C.4080405@gmail.com> <080uofog0bjf3jjes5m8smqk.1474390399527@email.android.com> Message-ID: <1C0F0C79-18C2-4EE3-9540-84945F278866@gmail.com> Some time ago I added http://erldocs.com/function.htm > On 20 Sep 2016, at 18:53, ?ric Pailleau wrote: > > Currently, we can use the external site http://erldocs.com/18.3/stdlib/ets.html?i=352 and change the version number in the URL to determine that the change occurred sometime in an 18.x release, but it would be nice to make things simpler. I have seen this be a problem more than once. While it is not perfect, it should be able to tell you on which releases your function exists. http://erldocs.com also sports a search bar that looks up Erlang code in all open source projects. I use it when I want to know what the best practices are when using this or that library. Im working on http://other.erldocs.com (latest version at https://dev.erldocs.com ). It is a daily build of all Erlang open source projects documentation. It has a /Repo/Tag/Application/Module.html format. Please note that erldocs is an open source project. You are more than welcome to file an issue or create pull requests. You can make the life of thousands of erldocs.com visitors easier! http://github.com/erldocs/erldocs/issues http://github.com/erldocs/erldocs/pulls -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Wed Sep 21 09:28:25 2016 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 21 Sep 2016 09:28:25 +0200 Subject: [erlang-questions] Erlang cookies, rpc, security, mnesia, hidden nodes, VPN tunnels and stuff! In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA301C28741C2@MAIL01.win.lbaum.eu> References: <12F2115FD1CCEE4294943B2608A18FA301C28741C2@MAIL01.win.lbaum.eu> Message-ID: <50595eed-9590-24f8-f2f6-b16a8cba9cfb@ericsson.com> FWIW: I use different cookies for different nodes in 'production'. A management node handles different pools, where each pool has its own cookie. The manager is hidden. Theoretically we could have many (10-50) pools with max 50 machines in each. In practice we only use 2-3 pools with 10-20 machines in each. bengt On 09/21/2016 09:20 AM, Tobias Schlager wrote: > Hi Trent, > > AFAIK it is possible to use different cookies for different nodes, the distribution protocol allows it. Furthermore it is possible to set different cookies on a node for remote nodes manually, see [1]. However, most probably this is not a good idea and I have to admit that I've never used this 'feature' (in production). > > Regards > Tobias > > [1] http://erlang.org/doc/man/erlang.html#set_cookie-2 > > ________________________________________ > Von: erlang-questions-bounces@REDACTED [erlang-questions-bounces@REDACTED]" im Auftrag von "Trent Hampton [trenthampton@REDACTED] > Gesendet: Dienstag, 20. September 2016 20:47 > An: erlang-questions@REDACTED > Betreff: [erlang-questions] Erlang cookies, rpc, security, mnesia, hidden nodes, VPN tunnels and stuff! > > Greetings Erlang Wizards! > > I have a client server erlang application where each server is connected to every other and is running an instance of an mnesia database across point to point VPN tunnels. > > I would like to be able to use erlang rpc on the clients to make function calls on the servers without exposing raw access to the mnesia database. That is, I do not want to expose, to the clients, the cookie that I use to connect mnesia nodes together. > > Is it possible to have the servers and mnesia communicate using one cookie but have the clients connect to the servers using another cookie so that the clients cannot gain access to the raw database and so that there are no transitive connections? > > According to http://erlang.org/doc/reference_manual/distributed.html section 13.3-5; it is possible to turn off transitive connections with the -connect_all false flag or by making a node hidden. Is it possible to use the hidden node and also use a different cookie for the client to server connection than the cookie used between the servers? > > Thank you! > > Trent > _______________________________________________ > 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 Wed Sep 21 09:32:13 2016 From: sergej.jurecko@REDACTED (=?utf-8?Q?Sergej_Jure=C4=8Dko?=) Date: Wed, 21 Sep 2016 09:32:13 +0200 Subject: [erlang-questions] Erlang cookies, rpc, security, mnesia, hidden nodes, VPN tunnels and stuff! In-Reply-To: References: Message-ID: <7457BD6A-F6BE-419F-91FF-2189A23FAC65@gmail.com> You can set a cookie for nodes: http://erlang.org/doc/man/erlang.html#set_cookie-2 So if your server node first connects to other mnesia nodes with a mnesia cookie, you can then set this to change default cookie for all other nodes (clients). Theoretically I think it should work. If I'm understanding your intention correctly you are attempting to add some security to an underlying system which has no security. There is nothing stopping clients from calling mnesia:.. functions on your server and do whatever they want. Unless clients are completely trusted, using erlang RPC for their connection is a really bad idea. regards, Sergej > On 20 Sep 2016, at 20:47, Trent Hampton wrote: > > Greetings Erlang Wizards! > > I have a client server erlang application where each server is connected to every other and is running an instance of an mnesia database across point to point VPN tunnels. > > I would like to be able to use erlang rpc on the clients to make function calls on the servers without exposing raw access to the mnesia database. That is, I do not want to expose, to the clients, the cookie that I use to connect mnesia nodes together. > > Is it possible to have the servers and mnesia communicate using one cookie but have the clients connect to the servers using another cookie so that the clients cannot gain access to the raw database and so that there are no transitive connections? > > According to http://erlang.org/doc/reference_manual/distributed.html section 13.3-5; it is possible to turn off transitive connections with the -connect_all false flag or by making a node hidden. Is it possible to use the hidden node and also use a different cookie for the client to server connection than the cookie used between the servers? > > Thank you! > > Trent > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Wed Sep 21 09:47:26 2016 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 21 Sep 2016 00:47:26 -0700 Subject: [erlang-questions] Erlang documentation In-Reply-To: <1C0F0C79-18C2-4EE3-9540-84945F278866@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <57E0FB9C.4080405@gmail.com> <080uofog0bjf3jjes5m8smqk.1474390399527@email.android.com> <1C0F0C79-18C2-4EE3-9540-84945F278866@gmail.com> Message-ID: <57E23B0E.2070204@gmail.com> On 09/21/2016 12:23 AM, Pierre Fenoll wrote: > Some time ago I added http://erldocs.com/function.htm > > On 20 Sep 2016, at 18:53, ?ric Pailleau > wrote: > >> Currently, we can use the external site http://erldocs.com/18.3/stdlib/ets.html?i=352 and change the version number in the URL to determine that the change occurred sometime in an 18.x release, but it would be nice to make things simpler. I have seen this be a problem more than once. > > While it is not perfect, it should be able to tell you on which releases your function exists. This is a very cool feature. Will use this in the future. Thanks! > > http://erldocs.com also sports a search bar that looks up Erlang code in all open source projects. > I use it when I want to know what the best practices are when using this or that library. > > Im working on http://other.erldocs.com (latest version at https://dev.erldocs.com ). > It is a daily build of all Erlang open source projects documentation. > It has a /Repo/Tag/Application/Module.html format. > > > Please note that erldocs is an open source project. You are more than welcome to file an issue or create pull requests. You can make the life of thousands of erldocs.com visitors easier! > > http://github.com/erldocs/erldocs/issues > http://github.com/erldocs/erldocs/pulls -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Wed Sep 21 12:41:12 2016 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 21 Sep 2016 12:41:12 +0200 Subject: [erlang-questions] Distributed OTP app not working when node is "-hidden" In-Reply-To: References: Message-ID: When using hidden nodes, the basic distribution semantics will work, but node discovery is disabled. I.e. the hidden node will not appear in the nodes() list of other nodes. This means that some applications that rely on nodes being visible will not work. Global and mnesia, for example. If all nodes are hidden, they will still have names, and can still connect to each other, but will not appear in the connection list. Example: uwpro:otp uwiger$ erl -name a -hidden Erlang/OTP 18 [erts-7.3.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.3.1 (abort with ^G) (a@REDACTED)1> uwpro:~ uwiger$ erl -name b -hidden Erlang/OTP 18 [erts-7.3.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.3.1 (abort with ^G) (b@REDACTED)1> net:ping('a@REDACTED'). pong (b@REDACTED)2> nodes(). [] (a@REDACTED)1> register(me, self()). true (b@REDACTED)3> {me, 'a@REDACTED'} ! hello. hello (b@REDACTED)4> (a@REDACTED)2> flush(). Shell got hello ok (a@REDACTED)3> You can write code that understands this, e.g. relying on some configuration database, but many existing components are likely to expect nodes to be visible. BR, Ulf W 2016-09-20 17:16 GMT+02:00 Frank Muller : > Hi everyone > > I've a simple OTP-compliant release, and I want to make it distributed on > two nodes. > > Following the steps here, it was pretty simple to achieve: > http://erlang.org/doc/design_principles/distributed_applications.html > > as long as my application is not "hidden". > > My constraint is that I need to keep my node "hidden" because it > connects to other critical nodes in our infrastructure. > > If I set "-hidden" in "vm.args", the distribution breaks and the two nodes > (the master and the backup) become both active, which is not desired :-( > > Anyone knows how to benefit from the distribution feature while keeping my > node "hidden"? > > Any other alternative(s) to solve my issue? > > Regards > Frank > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Wed Sep 21 12:52:53 2016 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 21 Sep 2016 11:52:53 +0100 Subject: [erlang-questions] Erlang documentation In-Reply-To: <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: On 21 September 2016 at 02:12, Richard A. O'Keefe wrote: > > On 20/09/16 8:20 PM, Roger Lipscombe wrote: >> >> I *do* wish that -- somehow -- the docs could be marked up so that a >> Google search would jump directly to the appropriate function. > > > Can you point us to documentation for some other project > where this works? I don't know if it *can* be made to work. I pointed to an example where, for some pages, Google returns links to headings on the page. It turns out that this is explained in this Google blog post: https://googleblog.blogspot.co.uk/2009/09/jump-to-information-you-want-right-from.html That seems to suggest that it's fairly basic -- that is: it lists likely-looking headings from the page, and not necessarily the ones you care about. I was kinda hoping that with some extra tags on the headings, Google might recognise which sections were actually relevant to the user's search and provide quick links to those. Regards, Roger. From kenneth.lundin@REDACTED Wed Sep 21 13:17:15 2016 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 21 Sep 2016 13:17:15 +0200 Subject: [erlang-questions] Erlang/OTP 19.1 has been released Message-ID: Erlang/OTP 19.1 is a service release on the 19 track with mostly bug fixes, but is does contain a number of new features and characteristics improvements as well. Some highlights of the release are: - erts: Improved dirty scheduler support. A purge of a module will not have to wait for completion of all ongoing dirty NIF calls. - erts: Improved accuracy of timeouts on MacOS X. - kernel: Add net_kernel:setopts/2 and net_kernel:getopts/2 to control options for distribution sockets in runtime. - asn1: Compiling multiple ASN.1 modules in the same directory with parallel make (make -j) should now be safe. - httpd: support for PUT and DELETE in mod_esi - ~30 contributions since 19.0 You can find the Release Notes with more detailed info at http://www.erlang.org/download/otp_src_19.1.readme You can download the full source distribution from http://www.erlang.org/download/otp_src_19.1.tar.gz Note: To unpack the TAR archive you need a GNU TAR compatible program. For installation instructions please read the README that is part of the distribution. You can also find the source code at github.com in the official Erlang repository. Git tag OTP-19.1 https://github.com/erlang/otp/tree/OTP-19.1 The Windows binary distributions can be downloaded from http://www.erlang.org/download/otp_win32_19.1.exe http://www.erlang.org/download/otp_win64_19.1.exe You can also download the complete HTML documentation or the Unix manual files http://www.erlang.org/download/otp_doc_html_19.1.tar.gz http://www.erlang.org/download/otp_doc_man_19.1.tar.gz You can also read the documentation on-line here: (see the Release Notes mentioned above for release notes which are not updated in the doc, but the new functionality is) http://www.erlang.org/doc/ We also want to thank those that sent us patches, suggestions and bug reports. If you find bugs in Erlang/OTP report them via the public issue tracker at http://bugs.erlang.org The Erlang/OTP Team at Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Sep 21 13:23:10 2016 From: ok@REDACTED (ok@REDACTED) Date: Wed, 21 Sep 2016 23:23:10 +1200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: By now I expect you've all seen my code which computes the check sums and has no calls to length/1 at all. I'd like to point out that it's straightforward to write length_is([_|Xs], N) when N > 0 -> length_is(Xs, N-1); length_is([], 0) -> true; length_is(_, _) -> false. which answers the question "is my first argument a list whose length matches my second argument" in O(min(|Xs|,N) time and to do f(..., Xs, ...) -> f(..., Xs, length_is(Xs, 137), ...). f(..., Xs, true, ...) -> % Xs is known to be a list of 137 elements ... It's not much harder to write length_between([_|Xs], L, U) when L > 0 -> length_between(Xs, L-1, U-1); length_between([], L, U) -> L =< 0, 0 =< U; length_between(_, _, _) -> false. and use it the same way. And of course, while it's *nice* to do pattern matching in the head, we *do* have 'case'. I was just marking some student code this afternoon which called a Java method f(N) five times with the same (large) value of N, the method having been implemented to take O(N) time instead of the easily achievable O(sort(N)). A very slow program. Yet not, mathematically considered, a stupid one. If Java had (or for that matter, *could* have) the notion of a "pure" method, constant subexpression elimination could have helped. (But not with O(N) vs O(sort(N)).) From ok@REDACTED Wed Sep 21 13:23:09 2016 From: ok@REDACTED (ok@REDACTED) Date: Wed, 21 Sep 2016 23:23:09 +1200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> Message-ID: <332fd25858149e60842174cd9e347faa.squirrel@chasm.otago.ac.nz> By now I expect you've all seen my code which computes the check sums and has no calls to length/1 at all. I'd like to point out that it's straightforward to write length_is([_|Xs], N) when N > 0 -> length_is(Xs, N-1); length_is([], 0) -> true; length_is(_, _) -> false. which answers the question "is my first argument a list whose length matches my second argument" in O(min(|Xs|,N) time and to do f(..., Xs, ...) -> f(..., Xs, length_is(Xs, 137), ...). f(..., Xs, true, ...) -> % Xs is known to be a list of 137 elements ... It's not much harder to write length_between([_|Xs], L, U) when L > 0 -> length_between(Xs, L-1, U-1); length_between([], L, U) -> L =< 0, 0 =< U; length_between(_, _, _) -> false. and use it the same way. And of course, while it's *nice* to do pattern matching in the head, we *do* have 'case'. I was just marking some student code this afternoon which called a Java method f(N) five times with the same (large) value of N, the method having been implemented to take O(N) time instead of the easily achievable O(sort(N)). A very slow program. Yet not, mathematically considered, a stupid one. If Java had (or for that matter, *could* have) the notion of a "pure" method, constant subexpression elimination could have helped. (But not with O(N) vs O(sort(N)).) From Catenacci@REDACTED Wed Sep 21 14:36:00 2016 From: Catenacci@REDACTED (Onorio Catenacci) Date: Wed, 21 Sep 2016 08:36:00 -0400 Subject: [erlang-questions] Chocolatey NuGet Installer For Erlang Message-ID: Hi all, I know this isn't a subject of wide interest but I did want to make sure that those folks who care about this are aware. There was an issue with silent install of Erlang via ChocolateyNuGet (CNG) on Windows. I have now resolved that issue and the latest Erlang 19 package (Erlang 19.0.20160907) on CNG should install silently with no issue whatever. As I say, I realize this isn't a matter of lots of interest but I do want to make sure those folks who use this are aware of this fix. -- Onorio Catenacci http://onor.io http://www.google.com/+OnorioCatenacci -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Sep 21 14:57:09 2016 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 21 Sep 2016 08:57:09 -0400 Subject: [erlang-questions] Learning from the Manual In-Reply-To: References: <3cd8294f76ca8b5efcc44f84cef81db7cee3d831@webmail.iinet.net.au> <20160920101840.otsbzrmkzidkvzcn@corelatus.se> Message-ID: <20160921125708.GH33990@fhebert-ltm2.internal.salesforce.com> On 09/21, Richard A. O'Keefe wrote: >On 20/09/16 10:18 PM, Matthias Lang wrote: >> http://learnyousomeerlang.com/content >> >>I took a look at his "datatype" section to see how he dealt with the >>"there aren't actually any strings" problem. And it turns out there is >>no string section! Perfect. > >The *paper* version has "strings" in the index, with > - as binaries > - a lists > - to a number >as subtopics. > Someone used the index! It's not anything special, but I'm glad to see there was something useful in there -- I tried my hand at the craft of indexing for the first time in the print copy of LYSE and dear lord there's a lot of stuff in there nobody suspects exists. The Chicago manual of style's pages on it were a revelation in terms of the unexpected complexity of things I usually just skip over. In any case, Matthias Lang does have a point where even though I mention strings, it is mostly done in passing. There's a mention of regular expressions (318, 325, 329-330), but topics having to do with the string module, the binary module (which I'm not even sure existed back then?) and topics having to do with Unicode are not discussed at all. Someone looking for common functionality such as title-casing text cannot find that information in LYSE (nor find out it isn't supported anywhere else than in community libraries [1]). LYSE was started around OTP-R13B. As we're nearing OTP-20, and within a very different community landscape than back then, there's more and more stuff that I feel is either missing, or no longer as important to show in the book as it was back then. I'd love to have time to work on a re-edition where stuff like releases could be made 50 pages shorter by using tools like relx, add material about the zen of erlang[2] and supervisor restarts[3], introduce maps within the normal text flow, get people more hands-on time with dialyzer and possibly property-based testing, make the FSM examples simpler, possibly using gen_statem instead of gen_fsm, and possibly replace stuff people use little of like distributed OTP releases and Mnesia to replace them with a crash course in using tools and libraries from rebar3 and the overall Erlang ecosystem for more common day-to-day tasks. That's without mentioning stuff like explaining how to get a proper SSL/TLS configuration going (the defaults are *not* safe), time handling (which could very well remain an annex), and so on. The website's also due for a facelift, fresher documentation links, and so on. I'd be interested to see what could be done with a more interactive version, where the website asks to contact a local Erlang server you run on your machine and lets you try snippets in JS (and therefore circumventing the need to sanitize Erlang on a server, which has proven hard and sometimes limitting before[4][5]). So far there's not enough time. Plenty busy at work, open source projects currently in flight (particularly rebar3) are fairly time consuming, and No Starch hasn't been showing much initiative in pushing for a new edition, but even then I'd probably want to get started on my own so I can easily control the rights to a free online version. There's also a bit of paralysis since I believe on of the reasons why LYSE went so well the first time around is that I was writing it as I was learning, and modifying it now would have me remove that perspective from it. The expert's eye is quite different from the newcomer's and manuals like Erlang in Anger[6] give a totally different experience. I'd like to maintain the current perspective in LYSE as much as possible, which could make it hard to accomplish some tasks such as say, move Dialyzer content earlier, or think of a new chapter flow that moves the user much closer to the action (although I can imagine using rebar3 and its shell to get the readers in a better place to explore on their own much earlier). [1]: https://github.com/erlang-unicode [2]: http://ferd.ca/the-zen-of-erlang.html [3]: http://ferd.ca/it-s-about-the-guarantees.html [4]: http://www.tryerlang.org/ [5]: http://erlangonxen.org/zerg is interesting though, but not quite sure how good isolation would be there [6]: https://www.erlang-in-anger.com From mononcqc@REDACTED Wed Sep 21 15:03:37 2016 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 21 Sep 2016 09:03:37 -0400 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <332fd25858149e60842174cd9e347faa.squirrel@chasm.otago.ac.nz> References: <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> <332fd25858149e60842174cd9e347faa.squirrel@chasm.otago.ac.nz> Message-ID: <20160921130336.GI33990@fhebert-ltm2.internal.salesforce.com> On 09/21, ok@REDACTED wrote: >It's not much harder to write > >length_between([_|Xs], L, U) when L > 0 -> > length_between(Xs, L-1, U-1); >length_between([], L, U) -> > L =< 0, 0 =< U; >length_between(_, _, _) -> > false. > >and use it the same way. And of course, while it's >*nice* to do pattern matching in the head, we *do* have 'case'. > Your Prolog is showing! The second clause there should have the body: length_between([], L, U) -> L =< 0 andalso 0 =< U; since the comma (`,') will execute the comparison in sequence, but only the result of `0 =< U' will be returned. From silviu.cpp@REDACTED Wed Sep 21 19:50:37 2016 From: silviu.cpp@REDACTED (Caragea Silviu) Date: Wed, 21 Sep 2016 20:50:37 +0300 Subject: [erlang-questions] all nodes in cluster crashing with eheap_alloc in the same time Message-ID: Hello guys, We have an Erlang server based on ejabberd (totally changed to fit our needs) which worked without any problem for 2 years. Suddenly for 2 weeks we had 3 big downtime's when all the nodes crashed in the same time with : eheap_alloc: Cannot allocate 18446744063279941840 bytes of memory (of type "heap_frag"). Of course the number of bytes was different but all over 18 GB. The servers are running on machines with 24 cores, around 300 GB memory. When crashed also didn't generated any crash dump and also core dump was not enabled on that machines. The fact that crash dump was not generated makes me believe it might be a problem in a NIF library but after this I found the following in the ERTS changelog: "Make sure to create a crash dump when running out of memory. This was accidentally removed in the erts-7.3 release." What we did fast was: 1. update to last erlang 19.0.7 2. compiled ourselves the virtual machine with systemtap enabled 3. enabled core dumps on all boxes 4. Limited all session process to 50 MB (process_flag(max_heap_size, ..)) and all other processes to 100 MB using erlang:system_flag(max_heap_size, ...) values being calculated as: -define(SESSION_MAX_HEAP_SIZE, get_env(session_max_heap_size, 10000000) div ?SYSTEM_WORDSIZE). -define(DEFAULT_MAX_HEAP_SIZE, get_env(default_max_heap_size, 10000000) div ?SYSTEM_WORDSIZE). where: {default_max_heap_size, 100000000}, {session_max_heap_size, 50000000}, Looking to the logs we can see so far time to time lot of: Process: <0.19379.617> on node 'prod@REDACTED' Context: maximum heap size reached Max Heap Size: 6250000 Total Heap Size: 30360946 Kill: true Error Logger: true GC Info: [{old_heap_block_size,10958},{heap_block_size,15405490},{mbuf_size,14944498},{recent_size,9},{stack_size,16},{old_heap_size,917},{heap_size,9},{bin_vheap_size,4295970},{bin_vheap_block_size,9235836},{bin_old_vheap_size,21},{bin_old_vheap_block_size,46422}] Observations: mbuf_size (which corresponds to message queue) is pretty big but also are bin_vheap numbers, which tells that the process allocates large binaries The only question I have now is : How I can make something to include in the logs more other info before process dies. like number of messages in the queue. We tried to setup also a monitor to be triggered way less than the limit where it has to be killed: Options = [{long_gc, 10000}, {large_heap, 1000000}, busy_port, busy_dist_port], erlang:system_monitor(self(), Options), handle_info({monitor, Pid, Type, Details}, State) -> log_system_event({Type, Pid, Details}), {noreply, State}; log_system_event({large_heap, GcPid, Info}) -> LogFun = fun() -> case recon:info(GcPid, messages) of {messages, Messages} -> ?WARNING_MSG("Large heap (~p): ~p~nProcess info: ~p~nProcess state size (words in the heap): ~p~nMessage queue(first 10):~p~n", [GcPid, Info, recon:info(GcPid), erts_debug:size(recon:get_state(GcPid)), Messages]); undefined -> ?WARNING_MSG("Large heap (~p): ~p~nProcess info is not available", [GcPid, Info]) end end, spawn(LogFun); But unfortunately the processes that has this issues have a life time small than 4 seconds. And this event is never triggered in time. Any help is appreciated ! Silviu -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandrashekhar.mullaparthi@REDACTED Wed Sep 21 23:59:08 2016 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Wed, 21 Sep 2016 22:59:08 +0100 Subject: [erlang-questions] Erlang cookies, rpc, security, mnesia, hidden nodes, VPN tunnels and stuff! In-Reply-To: References: Message-ID: Hi Trent, On 20 September 2016 at 19:47, Trent Hampton wrote: > Greetings Erlang Wizards! > > I have a client server erlang application where each server is connected > to every other and is running an instance of an mnesia database across > point to point VPN tunnels. > > I would like to be able to use erlang rpc on the clients to make function > calls on the servers without exposing raw access to the mnesia database. > That is, I do not want to expose, to the clients, the cookie that I use to > connect mnesia nodes together. > Try using 'erpc' - https://github.com/bet365/erpc It mostly has the same API as native rpc module, but on the server side you can specify access controls for each client. You can specify which client ips are allowed to connect, and for each incoming IP address, what combination of {Module, Function} are allowed. regards, Chandru -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Sep 22 03:04:31 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 22 Sep 2016 13:04:31 +1200 Subject: [erlang-questions] Erlang documentation In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <51222289-8471-6271-c0c7-802c563c4f1c@cs.otago.ac.nz> From the link that Roger Lipscome wrote, it sounds as though Google are doing "passage retrieval" within a page. That means that if you want a subpart of a page to be linked from the snippet, it's not something you do in the *page*, it's something you do in the *query*. You have to provide lots of keywords that are likely to be specific to the part you want. I tried Erlang list apply function concatenate results of map and flatmap showed up in the snippet just as I wanted, but there was no link in the snippet. Now that Erlang has function type specs, https://www.haskell.org/hoogle/ becomes of potential interest. Hoogle is a Haskell API search engine, which allows you to search many standard Haskell libraries by either function name, or by approximate type signature. For example, searching for (x -> [y]) -> [x] -> [y] in Hoogle comes back with concatMap at the top of the list, clicking on it takes you to the entry for concatMap, which actually says concatMap :: Foldable t => (a -> [b]) -> t a -> [b] [Source] Map a function over all the elements of a container and concatenate the resulting lists. The [Source] box is a link to the current source code. While Haddock + Hoogle is pretty cool, it could do with examples. I really should make more use of erldocs. From ok@REDACTED Thu Sep 22 03:07:41 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 22 Sep 2016 13:07:41 +1200 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <332fd25858149e60842174cd9e347faa.squirrel@chasm.otago.ac.nz> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> <332fd25858149e60842174cd9e347faa.squirrel@chasm.otago.ac.nz> Message-ID: <87f6d2d9-bfbb-05d6-7844-7f412755d88d@cs.otago.ac.nz> On 21/09/16 11:23 PM, ok@REDACTED wrote: > I'd like to point out that it's straightforward to write > > ... > > It's not much harder to write > > length_between([_|Xs], L, U) when L > 0 -> > length_between(Xs, L-1, U-1); > length_between([], L, U) -> > L =< 0, 0 =< U; > length_between(_, _, _) -> > false. The third clause was *meant* to be length_between([], L, U) when L =< 0, 0 =< U -> true; Free code. Worth every mill. Thanks to Fred H?bert for noticing this. Too much coffee, too late at night, and too much frustration with AirPort losing the signal every few seconds. From lloyd@REDACTED Thu Sep 22 03:33:41 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Wed, 21 Sep 2016 21:33:41 -0400 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <87f6d2d9-bfbb-05d6-7844-7f412755d88d@cs.otago.ac.nz> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> <332fd25858149e60842174cd9e347faa.squirrel@chasm.otago.ac.nz> <87f6d2d9-bfbb-05d6-7844-7f412755d88d@cs.otago.ac.nz> Message-ID: <49BB81E0-1C11-46C9-9699-9475046187FD@writersglen.com> Hi Richard, I finally had a chance to look closely at the ISBN validator function you sent me. It looks terrific, definitely addresses issues I would not have considered. So many thanks for taking the time to point the way. And thanks to all others who posted insights and suggestions. All the best, Lloyd Sent from my iPad > On Sep 21, 2016, at 9:07 PM, Richard A. O'Keefe wrote: > > > >> On 21/09/16 11:23 PM, ok@REDACTED wrote: >> I'd like to point out that it's straightforward to write >> > ... >> >> It's not much harder to write >> >> length_between([_|Xs], L, U) when L > 0 -> >> length_between(Xs, L-1, U-1); >> length_between([], L, U) -> >> L =< 0, 0 =< U; >> length_between(_, _, _) -> >> false. > > The third clause was *meant* to be > > length_between([], L, U) > when L =< 0, 0 =< U -> true; > > Free code. Worth every mill. > Thanks to Fred H?bert for noticing this. > Too much coffee, too late at night, and too much > frustration with AirPort losing the signal every > few seconds. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From josh.rubyist@REDACTED Thu Sep 22 05:45:39 2016 From: josh.rubyist@REDACTED (Josh Adams) Date: Wed, 21 Sep 2016 22:45:39 -0500 Subject: [erlang-questions] Quickcheck'ing a protocol Message-ID: So I've been frustrated lately by the fact that Slack's IRC gateway isn't RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) In dealing with this I wondered why the crap they needed an engineer to go through the spec as a result of their server's response to figure out that this was an issue (they've added it to their bug tracker, so I have some amount of faith it might get fixed eventually - for now I'll paper over the issue in the client which reduces the stress on them to actually fix it though). Should RFCs / protocols of this nature just come with something like a quickcheck model for their spec? Is anyone aware of prior art around this sort of thing aside from Quvic/Volvo that I could draw from if I wanted to fiddle in this arena? I'd think that the ideal situation involves an open source quickcheck implementation to test a given protocol implementation against at least some of the RFC, and a means to run the tests against potential servers/clients, with badges potentially showing the percentage of the test that passes. This would allow economics to drive spec implementers towards correctness, which would save countless engineer-hours spent figuring out why the damn clients can't talk to the damn servers for a given spec. Thoughts? Pipe dream? "Silly child, see A, B, and C for the many people who are already doing this?" -- Josh Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Thu Sep 22 07:57:58 2016 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Thu, 22 Sep 2016 07:57:58 +0200 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: Have you tried using PropEr / Quickcheck statem? http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html PropEr is free & open source & I use it to quickcheck RESTfull APIs. Cheers, -- Pierre Fenoll On 22 September 2016 at 05:45, Josh Adams wrote: > So I've been frustrated lately by the fact that Slack's IRC gateway isn't > RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) > > In dealing with this I wondered why the crap they needed an engineer to go > through the spec as a result of their server's response to figure out that > this was an issue (they've added it to their bug tracker, so I have some > amount of faith it might get fixed eventually - for now I'll paper over the > issue in the client which reduces the stress on them to actually fix it > though). > > Should RFCs / protocols of this nature just come with something like a > quickcheck model for their spec? Is anyone aware of prior art around this > sort of thing aside from Quvic/Volvo that I could draw from if I wanted to > fiddle in this arena? > > I'd think that the ideal situation involves an open source quickcheck > implementation to test a given protocol implementation against at least > some of the RFC, and a means to run the tests against potential > servers/clients, with badges potentially showing the percentage of the test > that passes. This would allow economics to drive spec implementers towards > correctness, which would save countless engineer-hours spent figuring out > why the damn clients can't talk to the damn servers for a given spec. > > Thoughts? Pipe dream? "Silly child, see A, B, and C for the many people > who are already doing this?" > > -- > Josh Adams > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From be.dmitry@REDACTED Thu Sep 22 10:58:26 2016 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Thu, 22 Sep 2016 18:58:26 +1000 Subject: [erlang-questions] List comprehension puzzler In-Reply-To: <20160921063033.GC3154@erix.ericsson.se> References: <1474217782.958230279@apps.rackspace.com> <1474379070.78336567@apps.rackspace.com> <20160920150018.GB3154@erix.ericsson.se> <18d389f6-e74b-a28e-50b2-36f0ff2a5e3f@gmail.com> <20160921063033.GC3154@erix.ericsson.se> Message-ID: <09DB0E76-8761-479E-996B-79BA473352C3@gmail.com> If you ever come back to this problem, let me suggest is_longer/2 as a little more readable alternative. And to make it even more useful let it accept iolists. On 21 September 2016 16:30:33 GMT+10:00, Raimo Niskanen wrote: >On Tue, Sep 20, 2016 at 03:53:55PM -0700, Kenneth Lakin wrote: >> On 09/20/2016 08:00 AM, Raimo Niskanen wrote: >> > Note that length(ISBN) will be called twice on this maybe very long >list, >> > and that in itself may be bad since length/1 is O(N). >> >> That seems easy enough to fix: >> >> when length(I) =< 13 andalso (length(I) == 10 orelse length(I) == 13) > >Sorry about being unclear. I should have written "... *called* (twice) >..." >since there is little greater harm in calling it twice than calling it >once. >It is still O(N) if you call it a constant number of times, and the >subsequent times it is likely that data is in the processor's cache >so they may be faster. > >The harm is in calling length/1 even once on a possibly very long list. > >We have had a suggestion to add a guard length(List, Max) >or max_length(List, Max) that would stop traversal after Max elements. > >This would be O(min(length(List), Max)), >which is O(Max), >which for a constant Max is O(1). > >But we never got to it... > >-- > >/ Raimo Niskanen, Erlang/OTP, Ericsson AB >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaobo.ye@REDACTED Thu Sep 22 11:41:14 2016 From: shaobo.ye@REDACTED (=?utf-8?B?5Y+25bCR5rOi?=) Date: Thu, 22 Sep 2016 17:41:14 +0800 Subject: [erlang-questions] How to dig why get_tcp/port allocate so much binary memory? Message-ID: Hi experts, I wrote a server that accepts TCP connections. The listen socket starts with the options below: -define(TCP_OPTS, [ binary, {backlog, 256}, {packet, 0}, {active, false}, {reuseaddr, true}, {nodelay, false}, {delay_send, true}, {keepalive, true}, {send_timeout, 60000}, {exit_on_close, true} ]). On the server node every new connection will spawn a new gen_server to handle it. And then I spawn 5000 gen_servers on another erlang node(I call it Client node), every gen_server will connect to the server via TCP. It is a really simple case. After setup 5000 connections I found the binary memory on server node was used up to 17G; and the binary memory on the Client node was 42M. It is a huge difference. Then I rebooted the erlang node with "+Mim true" and "+Mis true"; after re-setup 5000 connections again, I used instrument:memory_status(types) to check the memory status, I found the dry_binary allocated 17G memory: [{drv_binary,[{sizes,1844114912,1844116842,1844116842}, {blocks,5227,5724,5724}]}, {code,[{sizes,39944997,39955374,39955374}, {blocks,1321,1321,1321}]}, {heap,[{sizes,28000216,78942872,78942872}, {blocks,5263,5267,5267}]}, {old_heap,[{sizes,21132056,72481264,72481264}, {blocks,2940,4736,4736}]}, {binary,[{sizes,17908918,21738516,21738516}, {blocks,25087,35039,35039}]}, {proc_tab,[{sizes,12582975,12582975,12582975}, {blocks,1,1,1}]}, {export_entry,[{sizes,7108992,7108992,7108992}, {blocks,40392,40392,40392}]}, {db_term,[{sizes,6930120,6930200,6930200}, {blocks,13149,13150,13150}]}, {port_tab,[{sizes,6291519,6291519,6291519},{blocks,1,1,1}]}, {proc,[{sizes,4211200,4212800,4212800}, {blocks,5264,5266,5266}]}, {port,[{sizes,3392108,3393432,3393432}, {blocks,5101,5103,5103}]}, ....... My question is : How can I decrease the drv_binary memory? What parameter caused the server used so much memory? Thanks, BRs/Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Sep 22 13:17:40 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Thu, 22 Sep 2016 13:17:40 +0200 Subject: [erlang-questions] Download links not working? Message-ID: <8ed9f9cc-1a7e-b936-6526-43fe859b1579@ninenines.eu> As someone said on Twitter just now, the download links for Windows for 19.1 aren't working; but not just them, everything other than the README seems missing. This only concerns the links at the top of this page though: http://www.erlang.org/downloads - the links lower on the page are working. Cheers, -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From henrik.x.nord@REDACTED Thu Sep 22 14:22:32 2016 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Thu, 22 Sep 2016 14:22:32 +0200 Subject: [erlang-questions] Download links not working? In-Reply-To: <8ed9f9cc-1a7e-b936-6526-43fe859b1579@ninenines.eu> References: <8ed9f9cc-1a7e-b936-6526-43fe859b1579@ninenines.eu> Message-ID: <108e40b1-fc29-643f-a147-fcfbd8f8a0dd@ericsson.com> Yes thank you for pointing this out! fixed the links On 09/22/2016 01:17 PM, Lo?c Hoguin wrote: > As someone said on Twitter just now, the download links for Windows > for 19.1 aren't working; but not just them, everything other than the > README seems missing. > > This only concerns the links at the top of this page though: > http://www.erlang.org/downloads - the links lower on the page are > working. > > Cheers, > From Catenacci@REDACTED Thu Sep 22 14:31:03 2016 From: Catenacci@REDACTED (Onorio Catenacci) Date: Thu, 22 Sep 2016 08:31:03 -0400 Subject: [erlang-questions] Erlang/OTP 19.1 Message-ID: > > 3. Erlang/OTP 19.1 has been released (Kenneth Lundin) Wow, my timing is _fantastic!_ :-P I fix up the silent install on Erlang 19 just in time for 19.1. Seriously though, thanks to all of you who have created 19.1 I'll get to work on a CNG package for it just as soon as my time allows. -- Onorio Catenacci http://onor.io http://www.google.com/+OnorioCatenacci -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaobo.ye@REDACTED Thu Sep 22 14:35:16 2016 From: shaobo.ye@REDACTED (=?utf-8?B?5Y+25bCR5rOi?=) Date: Thu, 22 Sep 2016 20:35:16 +0800 Subject: [erlang-questions] How to dig why get_tcp/port allocate so muchbinary memory? In-Reply-To: References: Message-ID: Hi Motiejus? Thanks for your reply. My OS version is OS X 10.11.3; the erlang version is OTP18.3; the erlang compile flag is default, we don't change any configuration. The problem also exist on CentOS 6.4. Thanks, BRs/Michael ------------------ Original ------------------ From: "Motiejus Jak?tys"; Date: Thu, Sep 22, 2016 07:59 PM To: "???"; Subject: Re: [erlang-questions] How to dig why get_tcp/port allocate so muchbinary memory? Replying personally to reduce noise in the list, but it would be super helpful to know your OS, Erlang version and Erlang compile flags. A follow-up email would be worthwhile (as I can't answer you, but, with the information, there are people in this list that can). Motiejus On Thu, Sep 22, 2016 at 11:41 AM, ??? wrote: Hi experts, I wrote a server that accepts TCP connections. The listen socket starts with the options below: -define(TCP_OPTS, [ binary, {backlog, 256}, {packet, 0}, {active, false}, {reuseaddr, true}, {nodelay, false}, {delay_send, true}, {keepalive, true}, {send_timeout, 60000}, {exit_on_close, true} ]). On the server node every new connection will spawn a new gen_server to handle it. And then I spawn 5000 gen_servers on another erlang node(I call it Client node), every gen_server will connect to the server via TCP. It is a really simple case. After setup 5000 connections I found the binary memory on server node was used up to 17G; and the binary memory on the Client node was 42M. It is a huge difference. Then I rebooted the erlang node with "+Mim true" and "+Mis true"; after re-setup 5000 connections again, I used instrument:memory_status(types) to check the memory status, I found the dry_binary allocated 17G memory: [{drv_binary,[{sizes,1844114912,1844116842,1844116842}, {blocks,5227,5724,5724}]}, {code,[{sizes,39944997,39955374,39955374}, {blocks,1321,1321,1321}]}, {heap,[{sizes,28000216,78942872,78942872}, {blocks,5263,5267,5267}]}, {old_heap,[{sizes,21132056,72481264,72481264}, {blocks,2940,4736,4736}]}, {binary,[{sizes,17908918,21738516,21738516}, {blocks,25087,35039,35039}]}, {proc_tab,[{sizes,12582975,12582975,12582975}, {blocks,1,1,1}]}, {export_entry,[{sizes,7108992,7108992,7108992}, {blocks,40392,40392,40392}]}, {db_term,[{sizes,6930120,6930200,6930200}, {blocks,13149,13150,13150}]}, {port_tab,[{sizes,6291519,6291519,6291519},{blocks,1,1,1}]}, {proc,[{sizes,4211200,4212800,4212800}, {blocks,5264,5266,5266}]}, {port,[{sizes,3392108,3393432,3393432}, {blocks,5101,5103,5103}]}, ....... My question is : How can I decrease the drv_binary memory? What parameter caused the server used so much memory? Thanks, BRs/Michael _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- Motiejus Jak?tys -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andras.Bekes@REDACTED Thu Sep 22 14:51:38 2016 From: Andras.Bekes@REDACTED (Bekes, Andras G) Date: Thu, 22 Sep 2016 12:51:38 +0000 Subject: [erlang-questions] {error,closed} vs. {error,econnreset} References: <54E4A07E.5010307@erlang.org> <20150502103209.GA19880@nybek.com> <20150624124817.GA30126@nybek.com> Message-ID: Hi Rory, All, Let me revive this old thread for a minute. The new gen_tcp option {show_econnreset, true} works well. However, we still notice some cases when we observe {error,closed} on the Erlang side, but other signs suggest that the TCP connection wasn't intentionally closed by the peer, but was closed because of some error. We suspect some packets being dropped by the OS due to various buffer overruns. I am not very familiar with packet-level details of TCP. Can someone confirm if there are other erroneous terminations of a TCP connection (other than econnreset), reported simply as {error,closed} by Erlang? I tried checking the code erts/emulator/drivers/common/inet_drv.c and it seems to me not, but can someone actually understanding that code also confirm? Thank you very much, Andras -----Original Message----- From: Bekes, Andras G (ICT) Sent: Tuesday, August 11, 2015 2:43 PM To: 'Rory Byrne'; erlang-questions@REDACTED Subject: RE: [erlang-questions] {error,closed} vs. {error,econnreset} Hi Rory, I just tested this new feature in Erlang/OTP R18 and it works fine. Thank you very much all for implementing it! Regards, Andras -----Original Message----- From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Rory Byrne Sent: Wednesday, June 24, 2015 2:48 PM To: erlang-questions@REDACTED Subject: Re: [erlang-questions] {error,closed} vs. {error,econnreset} Hi Andras, On Tue, May 05, 2015 at 07:44:47AM +0000, Bekes, Andras G wrote: > Thank you very much for your efforts Rory. > > The ability "to set a socket option that shows all econnreset errors" sounds like the right solution. I am wondering why hiding this detail is the default, but I believe there were good enough reasons to design it that way. > > I accept that your solution will not notice the connection reset event in some corner cases. I think this will not apply in my case: I am sending a small amount of data (<1KB) and wait for the reply. > > I am looking forward to see your patch in the next release of Erlang/OTP! The fix for this is in the 18.0 release. It should take care of the corner cases too. Use the socket option '{show_econnreset, true}' and you'll receive {error, econnreset} in passive mode or {tcp_error, Socket, econnreset} in active mode. See the docs [1] for more information. Regards, Rory [1] http://www.erlang.org/doc/man/inet.html#setopts-2 _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From z@REDACTED Thu Sep 22 15:06:05 2016 From: z@REDACTED (Danil Zagoskin) Date: Thu, 22 Sep 2016 16:06:05 +0300 Subject: [erlang-questions] How to dig why get_tcp/port allocate so much binary memory? In-Reply-To: References: Message-ID: Hi! Please check your recbuf and sndbuf port options. After you establish a conection, log buffer sizes somehow, e.g. io:format("Socket buffers: ~w~n", [inet:getopts(S, [recbuf, sndbuf])]). Large socket buffers are nice thing to have (for high throughput), but they can eat all your memory really fast. If they are not set explicitly by your application, you can check inet_default_connect_options kernel app environment variable or your operating system defaults (rmem_default). On Thu, Sep 22, 2016 at 12:41 PM, ??? wrote: > Hi experts, > > I wrote a server that accepts TCP connections. The listen socket starts > with the options below: > -define(TCP_OPTS, [ > binary, > {backlog, 256}, > {packet, 0}, > {active, false}, > {reuseaddr, true}, > {nodelay, false}, > {delay_send, true}, > {keepalive, true}, > {send_timeout, 60000}, > {exit_on_close, true} > ]). > On the server node every new connection will spawn a new gen_server to > handle it. > > And then I spawn 5000 gen_servers on another erlang node(I call it Client > node), every gen_server will connect to the server via TCP. > > It is a really simple case. > > After setup 5000 connections I found the binary memory on server node was > used up to 17G; > and the binary memory on the Client node was 42M. It is a huge difference. > > Then I rebooted the erlang node with "+Mim true" and "+Mis true"; after > re-setup 5000 connections again, I used > instrument:memory_status(types) to check the memory status, I found the > dry_binary allocated 17G memory: > [{drv_binary,[{sizes,1844114912,1844116842,1844116842}, > {blocks,5227,5724,5724}]}, > {code,[{sizes,39944997,39955374,39955374}, > {blocks,1321,1321,1321}]}, > {heap,[{sizes,28000216,78942872,78942872}, > {blocks,5263,5267,5267}]}, > {old_heap,[{sizes,21132056,72481264,72481264}, > {blocks,2940,4736,4736}]}, > {binary,[{sizes,17908918,21738516,21738516}, > {blocks,25087,35039,35039}]}, > {proc_tab,[{sizes,12582975,12582975,12582975}, > {blocks,1,1,1}]}, > {export_entry,[{sizes,7108992,7108992,7108992}, > {blocks,40392,40392,40392}]}, > {db_term,[{sizes,6930120,6930200,6930200}, > {blocks,13149,13150,13150}]}, > {port_tab,[{sizes,6291519,6291519,6291519},{blocks,1,1,1}]}, > {proc,[{sizes,4211200,4212800,4212800}, > {blocks,5264,5266,5266}]}, > {port,[{sizes,3392108,3393432,3393432}, > {blocks,5101,5103,5103}]}, > ....... > > My question is : How can I decrease the drv_binary memory? What parameter > caused the server used so much memory? > > Thanks, > BRs/Michael > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaobo.ye@REDACTED Thu Sep 22 17:06:49 2016 From: shaobo.ye@REDACTED (=?gb18030?B?0rbJ2bKo?=) Date: Thu, 22 Sep 2016 23:06:49 +0800 Subject: [erlang-questions] =?gb18030?q?Re=A3=BARe=3A__How_to_dig_why_get?= =?gb18030?q?=5Ftcp/port_allocate_so_muchbinary_memory=3F?= Message-ID: Hi Danil, Thanks for your answer. Actually I have tried the solution you suggested, I set the sndbuf and recbuf to 1024, the result is same, 17G memory was used. I tried to get the sndbuf and recbuf after the connections setup, the sndbuf is 1024, but the recbuf is very big, seems 436322 if I remember correctly. And on my Client node, I checked the sndbuf and recbuf of all the connections, they are all very big, but the used binary memory is small, 20Mb. Thanks, Bars/Michael ---????--- ???:"Danil Zagoskin" ????:2016?9?22?(???) ??9:06 ???:"???"; ??: [erlang-questions] How to dig why get_tcp/port allocate so muchbinary memory? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yueyoum@REDACTED Thu Sep 22 18:39:59 2016 From: yueyoum@REDACTED (=?UTF-8?B?5pyI5b+n6IyX?=) Date: Fri, 23 Sep 2016 00:39:59 +0800 Subject: [erlang-questions] How to specify a clear map type Message-ID: According this document: http://erlang.org/doc/reference_manual/typespec.html I can define a map type like this: -type my_type() :: #{integer() := string()}. I have a map called State, it's type is `my_type`, key type is integer, value type is string. -spec find_value(atom(), my_type()) -> string(). > find_value(Key, State) when is_atom(Key) -> > #{Key := Value} = State, > Value. Using dialyzer analysis the file. nothing happens. dialyzer say there is no error for this file. I know maps are dynamic, my_type() just meas this map must have a integer key associated with a string value. But not limit to add other type key and value in the map. My question is that Is it possible limit the map types of key and value ? So dialyzer can find the match error in my program. -- My GitHub https://github.com/yueyoum -------------- next part -------------- An HTML attachment was scrubbed... URL: From rexxe98@REDACTED Thu Sep 22 19:53:23 2016 From: rexxe98@REDACTED (Andrew Berman) Date: Thu, 22 Sep 2016 17:53:23 +0000 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: Hey Pierre, How do you QuickCheck RESTful APIs? I'm a noobie with QuickCheck and using it with RESTful APIs would be really useful to me. Do you have any sample code or is there a tutorial anywhere? Thanks! On Wed, Sep 21, 2016 at 10:58 PM Pierre Fenoll wrote: > Have you tried using PropEr / Quickcheck statem? > http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html > PropEr is free & open source & I use it to quickcheck RESTfull APIs. > > > > Cheers, > -- > Pierre Fenoll > > On 22 September 2016 at 05:45, Josh Adams wrote: > >> So I've been frustrated lately by the fact that Slack's IRC gateway isn't >> RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) >> >> In dealing with this I wondered why the crap they needed an engineer to >> go through the spec as a result of their server's response to figure out >> that this was an issue (they've added it to their bug tracker, so I have >> some amount of faith it might get fixed eventually - for now I'll paper >> over the issue in the client which reduces the stress on them to actually >> fix it though). >> >> Should RFCs / protocols of this nature just come with something like a >> quickcheck model for their spec? Is anyone aware of prior art around this >> sort of thing aside from Quvic/Volvo that I could draw from if I wanted to >> fiddle in this arena? >> >> I'd think that the ideal situation involves an open source quickcheck >> implementation to test a given protocol implementation against at least >> some of the RFC, and a means to run the tests against potential >> servers/clients, with badges potentially showing the percentage of the test >> that passes. This would allow economics to drive spec implementers towards >> correctness, which would save countless engineer-hours spent figuring out >> why the damn clients can't talk to the damn servers for a given spec. >> >> Thoughts? Pipe dream? "Silly child, see A, B, and C for the many people >> who are already doing this?" >> >> -- >> Josh Adams >> >> _______________________________________________ >> 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 yueyoum@REDACTED Thu Sep 22 20:05:00 2016 From: yueyoum@REDACTED (=?UTF-8?B?5pyI5b+n6IyX?=) Date: Fri, 23 Sep 2016 02:05:00 +0800 Subject: [erlang-questions] Performance of type_to_type functions Message-ID: integer_to_list > integer_to_binary > atom_to_binary > ... how about the performance of this type to type function? can I using this function wildly? -- My GitHub https://github.com/yueyoum -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrallen1@REDACTED Thu Sep 22 21:30:57 2016 From: mrallen1@REDACTED (Mark Allen) Date: Thu, 22 Sep 2016 19:30:57 +0000 (UTC) Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: <1853120823.3184935.1474572657983@mail.yahoo.com> Josh, Have you looked at Scribble? http://scribble.org/ On Wednesday, September 21, 2016 10:45 PM, Josh Adams wrote: So I've been frustrated lately by the fact that Slack's IRC gateway isn't RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) In dealing with this I wondered why the crap they needed an engineer to go through the spec as a result of their server's response to figure out that this was an issue (they've added it to their bug tracker, so I have some amount of faith it might get fixed eventually - for now I'll paper over the issue in the client which reduces the stress on them to actually fix it though). Should RFCs / protocols of this nature just come with something like a quickcheck model for their spec?? Is anyone aware of prior art around this sort of thing aside from Quvic/Volvo that I could draw from if I wanted to fiddle in this arena? I'd think that the ideal situation involves an open source quickcheck implementation to test a given protocol implementation against at least some of the RFC, and a means to run the tests against potential servers/clients, with badges potentially showing the percentage of the test that passes.? This would allow economics to drive spec implementers towards correctness, which would save countless engineer-hours spent figuring out why the damn clients can't talk to the damn servers for a given spec. Thoughts?? Pipe dream? ?"Silly child, see A, B, and C for the many people who are already doing this?" -- Josh Adams _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Thu Sep 22 21:51:24 2016 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 22 Sep 2016 21:51:24 +0200 Subject: [erlang-questions] Performance of type_to_type functions In-Reply-To: References: Message-ID: <22500.13884.316262.231728@gargle.gargle.HOWL> ??? writes: > integer_to_list > > integer_to_binary > > atom_to_binary > > ... > > > how about the performance of this type to type function? > can I using this function wildly? You can, but you shouldn't because they need to allocate and initialize memory in order to produce the alternative value representation you're asking for (say, from the integer 55 to the list [$5, $5]). And that's in addition to whatever type checking they have to perform first. So no they're not "free". From james@REDACTED Thu Sep 22 22:28:39 2016 From: james@REDACTED (James Aimonetti) Date: Thu, 22 Sep 2016 20:28:39 +0000 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: <87fuor65mw.fsf@2600hz.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 You should check out Thomas Arts' talk from this past Erlang Factory: https://www.youtube.com/watch?v=iW2J7Of8jsE The ideas should be generally applicable. Andrew Berman writes: > Hey Pierre, > > How do you QuickCheck RESTful APIs? I'm a noobie with QuickCheck and using > it with RESTful APIs would be really useful to me. Do you have any sample > code or is there a tutorial anywhere? > > Thanks! > > On Wed, Sep 21, 2016 at 10:58 PM Pierre Fenoll > wrote: > >> Have you tried using PropEr / Quickcheck statem? >> http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html >> PropEr is free & open source & I use it to quickcheck RESTfull APIs. >> >> >> >> Cheers, >> -- >> Pierre Fenoll >> >> On 22 September 2016 at 05:45, Josh Adams wrote: >> >>> So I've been frustrated lately by the fact that Slack's IRC gateway isn't >>> RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) >>> >>> In dealing with this I wondered why the crap they needed an engineer to >>> go through the spec as a result of their server's response to figure out >>> that this was an issue (they've added it to their bug tracker, so I have >>> some amount of faith it might get fixed eventually - for now I'll paper >>> over the issue in the client which reduces the stress on them to actually >>> fix it though). >>> >>> Should RFCs / protocols of this nature just come with something like a >>> quickcheck model for their spec? Is anyone aware of prior art around this >>> sort of thing aside from Quvic/Volvo that I could draw from if I wanted to >>> fiddle in this arena? >>> >>> I'd think that the ideal situation involves an open source quickcheck >>> implementation to test a given protocol implementation against at least >>> some of the RFC, and a means to run the tests against potential >>> servers/clients, with badges potentially showing the percentage of the test >>> that passes. This would allow economics to drive spec implementers towards >>> correctness, which would save countless engineer-hours spent figuring out >>> why the damn clients can't talk to the damn servers for a given spec. >>> >>> Thoughts? Pipe dream? "Silly child, see A, B, and C for the many people >>> who are already doing this?" >>> >>> -- >>> Josh Adams >>> >>> _______________________________________________ >>> 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 - -- James Aimonetti Lead Systems Architect "If Dialyzer don't care, I don't care" 2600HzPDX | http://2600hz.com sip:james@REDACTED tel:415.886.7905 irc:mc_ @ freenode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX5D73AAoJENTKa+JPXCVg8SwH/jTe/EhqLBQc1b82rptahsuy SL2dwQjzq6kxfzJquVE05t4yjjhI3GKaHoaeGkPMNF4Wq4Y9ZdWVOrIfyE1fHuxg EltLgUq6OAjQeCYkQXNOTtcWzt6AJ8ZpKK9z9U7hydJL9NAs1IF6v2D/NjbvJ02H OAlRLZzhqcN1nm+/yOPPqs9zBac5SR3YHK3bo8A5vlx5M+8jrI3SV6fe5cBXTbIF CzVKmrlD3EZlGEYaDN1ssFDShv42CZJk4+2bvQnsJDJ4YRe7WqoDOJIhgcg92Tuo ntiYR8nlMY+qzDWYjOZnpVNNUN5oudLUjmhCuLU5vGwkLB74Y+2YBwxbC7gabec= =KvP6 -----END PGP SIGNATURE----- From josh.rubyist@REDACTED Thu Sep 22 22:37:22 2016 From: josh.rubyist@REDACTED (Josh Adams) Date: Thu, 22 Sep 2016 15:37:22 -0500 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: <1853120823.3184935.1474572657983@mail.yahoo.com> References: <1853120823.3184935.1474572657983@mail.yahoo.com> Message-ID: I have not seen it. The user forum appears to have zero posts and the developer forum a handful ending in 2014. This is not immediately encouraging :) Thanks though, will try to dig further :) On Thu, Sep 22, 2016 at 2:30 PM, Mark Allen wrote: > Josh, > > Have you looked at Scribble? http://scribble.org/ > > > > > > > On Wednesday, September 21, 2016 10:45 PM, Josh Adams < > josh.rubyist@REDACTED> wrote: > > > So I've been frustrated lately by the fact that Slack's IRC gateway isn't > RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) > > In dealing with this I wondered why the crap they needed an engineer to go > through the spec as a result of their server's response to figure out that > this was an issue (they've added it to their bug tracker, so I have some > amount of faith it might get fixed eventually - for now I'll paper over the > issue in the client which reduces the stress on them to actually fix it > though). > > Should RFCs / protocols of this nature just come with something like a > quickcheck model for their spec? Is anyone aware of prior art around this > sort of thing aside from Quvic/Volvo that I could draw from if I wanted to > fiddle in this arena? > > I'd think that the ideal situation involves an open source quickcheck > implementation to test a given protocol implementation against at least > some of the RFC, and a means to run the tests against potential > servers/clients, with badges potentially showing the percentage of the test > that passes. This would allow economics to drive spec implementers towards > correctness, which would save countless engineer-hours spent figuring out > why the damn clients can't talk to the damn servers for a given spec. > > Thoughts? Pipe dream? "Silly child, see A, B, and C for the many people > who are already doing this?" > > -- > Josh Adams > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- Josh Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Sep 22 22:38:25 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 22 Sep 2016 22:38:25 +0200 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: On Thu, Sep 22, 2016 at 5:45 AM, Josh Adams wrote: > Should RFCs / protocols of this nature just come with something like a > quickcheck model for their spec? In principle, protocols should come with two things: * A set of parser combinators which fit into a framework such as Meredith Patterson's Hammer. This would make it next to impossible to accidentally parse the protocol wrong and establish syntactically valid input. In an Erlang world, it would produce proper Erlang terms. * A QuickCheck specification. This would allow implementors to verify their protocol against a quasi-formal model which would greatly improve quality of software. Every implementation would be at least as precise as the QC model. A more ambitious solution would include a model closer to e.g. TLA+. Then one writes a compiler from TLA+ to a QC system and you can check real-world programs. I think the reason it is not done has to do with effort. Doing the right thing(tm) often takes an order of magnitude more time compared to the quick and dirty hack. Since software is built primarily on the basis of speed (time), people don't do the necessary work up front. Rather, it is baked on later, when the damage has been done. Up front modeling often changes the spec in ways which removes ambiguity and room for error. If we should start, *the* place to start is TLS 1.3 :P -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.rubyist@REDACTED Thu Sep 22 22:43:31 2016 From: josh.rubyist@REDACTED (Josh Adams) Date: Thu, 22 Sep 2016 15:43:31 -0500 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: > > In principle, protocols should come with two things: > > * A set of parser combinators which fit into a framework such as Meredith > Patterson's Hammer. This would make it next to impossible to accidentally > parse the protocol wrong and establish syntactically valid input. In an > Erlang world, it would produce proper Erlang terms. > > * A QuickCheck specification. This would allow implementors to verify > their protocol against a quasi-formal model which would greatly improve > quality of software. Every implementation would be at least as precise as > the QC model. A more ambitious solution would include a model closer to > e.g. TLA+. Then one writes a compiler from TLA+ to a QC system and you can > check real-world programs. > > I think the reason it is not done has to do with effort. Doing the right > thing(tm) often takes an order of magnitude more time compared to the quick > and dirty hack. Since software is built primarily on the basis of speed > (time), people don't do the necessary work up front. Rather, it is baked on > later, when the damage has been done. Up front modeling often changes the > spec in ways which removes ambiguity and room for error. > > If we should start, *the* place to start is TLS 1.3 :P > This all sounds amazing and like a thing I'd like to encourage the world to adopt. Any thoughts on a very simple protocol one could get started in? If we could get a few similarly-written examples in place and popularized perhaps it could encourage adoption? Bonus if we can define a service that checks an implementation, provide 'badges' that link to the service, and convince some implementations of the initial test protocols to link to them in their READMEs/sites :) I just started doing math on this sort of thing recently and when I consider the amount of time wasted (at least 4 hours of my time just to prove that slack failed to adhere to the IRC RFC) times the number of engineers that have inevitably run into the same thing, it really sickens me. As software continues to eat the world, I expect there to be a short asymptote to how much we can feasibly do unless we start handling things more correctly as a society. There's...just no acceptable reason to have the situation we presently have, at this stage in our field :( I'd be glad to do a few episodes of my screencast on this sort of thing, which (a) would justify my spending the time on such a project, and (b) might help me popularize the idea / get other people up in arms about it. I'd need some help though because I'm a bit out of my depth here :) -- Josh Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Thu Sep 22 23:56:30 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Thu, 22 Sep 2016 17:56:30 -0400 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: Hello, To date, this thread has generated quite a few worthwhile insights and ideas. My fear is that they will be deep-sixed into the archive. On the other hand, major revision is a daunting task and unlikely to happen. But maybe we can focus on specific issues and make iterative headway. Fewer than half of the functions in the lists library, for instance, have code examples. Suppose over the span of one week we were collectively focus on generating at least two code examples for each function in one library. At the end of the week we could organize the submissions and vote on best candidates for inclusion in the docs. That done, we can pick another module. Thus, with not much effort from any one individual, a small posse of volunteer Erlang wizards could make short work of deficiencies in the docs. Anyway, it's an idea. All the best, LRP Sent from my iPad > On Sep 21, 2016, at 6:52 AM, Roger Lipscombe wrote: > >> On 21 September 2016 at 02:12, Richard A. O'Keefe wrote: >> >>> On 20/09/16 8:20 PM, Roger Lipscombe wrote: >>> >>> I *do* wish that -- somehow -- the docs could be marked up so that a >>> Google search would jump directly to the appropriate function. >> >> >> Can you point us to documentation for some other project >> where this works? > > I don't know if it *can* be made to work. I pointed to an example > where, for some pages, Google returns links to headings on the page. > It turns out that this is explained in this Google blog post: > https://googleblog.blogspot.co.uk/2009/09/jump-to-information-you-want-right-from.html > > That seems to suggest that it's fairly basic -- that is: it lists > likely-looking headings from the page, and not necessarily the ones > you care about. I was kinda hoping that with some extra tags on the > headings, Google might recognise which sections were actually relevant > to the user's search and provide quick links to those. > > Regards, > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From margnus1@REDACTED Fri Sep 23 01:01:01 2016 From: margnus1@REDACTED (=?UTF-8?Q?Magnus_L=c3=a5ng?=) Date: Fri, 23 Sep 2016 01:01:01 +0200 Subject: [erlang-questions] How to specify a clear map type In-Reply-To: References: Message-ID: On 2016-09-22 18:39, ??? wrote: > According this document: > http://erlang.org/doc/reference_manual/typespec.html > > I can define a map type like this: > > -type my_type() :: #{integer() := string()}. > > > I have a map called State, it's type is `my_type`, key type is > integer, value type is string. > > -spec find_value(atom(), my_type()) -> string(). > find_value(Key, State) when is_atom(Key) -> > #{Key := Value} = State, > Value. > > > > Using dialyzer analysis the file. nothing happens. > dialyzer say there is no error for this file. > > I know maps are dynamic, my_type() just meas this map must have a > integer key associated with a string value. > But not limit to add other type key and value in the map. > > My question is that Is it possible limit the map types of key and value ? > So dialyzer can find the match error in my program. Actually, your type is already restricted in this way, and I'm surprised your find_value example does not produce any warnings. Dialyzer should be quite capable of finding the problem. Indeed, if we enforce the type of the State argument in this (slightly ridiculous) way instead of using a type specification, the problem /is/ found: find_value(Key, State) -> StateList = [{K, V} || {K, V} <- maps:to_list(State), is_integer(K), is_list(V)], find_value_1(Key, maps:from_list(StateList)). find_value_1(Key, State) when is_atom(Key) -> #{Key := Value} = State, Value. When I get some time over, I'll have a look at why your example does not fail, but for now rest assured that your type syntax is correct and means what you want it to mean. // Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Fri Sep 23 01:33:48 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Thu, 22 Sep 2016 16:33:48 -0700 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> On 09/22/2016 02:56 PM, Lloyd R. Prentice wrote: > Fewer than half of the functions in the lists library, > for instance, have code examples. Suppose over the span > of one week we were collectively focus on generating at > least two code examples for each function in one library. Many of the functions in many of the libs are already sufficiently documented. Ferinstance, once one has read the explanatory prose for the relevant function, does one need code examples for lists:reverse/1 ? lists:sort/1 ? erlang:is_[binary|list|...]/1 ? I recognize the core reason for your challenge, but I'll take this time to point out that https://github.com/erlang/otp/pulls exists and -AFAIK- accepts documentation updates. Initially it can be a little confusing to figure out where the various documentation files live. Remember that the .html files in the online documentation are created from .xml files with the same name (but not in the same location) in the Erlang repo. (For example: doc/man/erl_driver.html is created from $ERL_TOP/erts/doc/src/erl_driver.xml .) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mkbucc@REDACTED Fri Sep 23 02:54:15 2016 From: mkbucc@REDACTED (Mark Bucciarelli) Date: Thu, 22 Sep 2016 20:54:15 -0400 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On Thu, Sep 22, 2016 at 7:33 PM, Kenneth Lakin wrote: > > I'll take this time to point out that https://github.com/erlang/otp/pulls > exists and -AFAIK- accepts documentation updates. > +1 > Initially it can be a little confusing to figure out where the various > documentation files live. Remember that the .html files in the online > documentation are created from .xml files with the same name (but not in the > same location) in the Erlang repo. (For example: doc/man/erl_driver.html is > created from $ERL_TOP/erts/doc/src/erl_driver.xml.) Those five lines right there are a PR-in-waiting for (the new file) otp/HOWTO/WRITE-DOCUMENTATION.md. Mark -- Blogging at markbucciarelli.com Tweeting @mbucc -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Sep 23 02:55:57 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 23 Sep 2016 02:55:57 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On 09/23/2016 01:33 AM, Kenneth Lakin wrote: > On 09/22/2016 02:56 PM, Lloyd R. Prentice wrote: >> Fewer than half of the functions in the lists library, >> for instance, have code examples. Suppose over the span >> of one week we were collectively focus on generating at >> least two code examples for each function in one library. > > Many of the functions in many of the libs are already sufficiently > documented. Ferinstance, once one has read the explanatory prose for the > relevant function, does one need code examples for lists:reverse/1 ? > lists:sort/1 ? erlang:is_[binary|list|...]/1 ? Yes. Someone with no experience will always appreciate them. Not to mention that "sorted" in Erlang has a very specific meaning, which is not defined at all in the documentation for lists:sort/1. Examples are never a bad thing to have; at worst they provide no value for the majority of people; at best they are easier to understand than the description. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From rexxe98@REDACTED Fri Sep 23 02:56:33 2016 From: rexxe98@REDACTED (Andrew Berman) Date: Fri, 23 Sep 2016 00:56:33 +0000 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: <87fuor65mw.fsf@2600hz.com> References: <87fuor65mw.fsf@2600hz.com> Message-ID: Cool, thanks! On Thu, Sep 22, 2016 at 1:28 PM James Aimonetti wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > You should check out Thomas Arts' talk from this past Erlang Factory: > > https://www.youtube.com/watch?v=iW2J7Of8jsE > > The ideas should be generally applicable. > > Andrew Berman writes: > > > Hey Pierre, > > > > How do you QuickCheck RESTful APIs? I'm a noobie with QuickCheck and > using > > it with RESTful APIs would be really useful to me. Do you have any > sample > > code or is there a tutorial anywhere? > > > > Thanks! > > > > On Wed, Sep 21, 2016 at 10:58 PM Pierre Fenoll > > wrote: > > > >> Have you tried using PropEr / Quickcheck statem? > >> > http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html > >> PropEr is free & open source & I use it to quickcheck RESTfull APIs. > >> > >> > >> > >> Cheers, > >> -- > >> Pierre Fenoll > >> > >> On 22 September 2016 at 05:45, Josh Adams > wrote: > >> > >>> So I've been frustrated lately by the fact that Slack's IRC gateway > isn't > >>> RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) > >>> > >>> In dealing with this I wondered why the crap they needed an engineer to > >>> go through the spec as a result of their server's response to figure > out > >>> that this was an issue (they've added it to their bug tracker, so I > have > >>> some amount of faith it might get fixed eventually - for now I'll paper > >>> over the issue in the client which reduces the stress on them to > actually > >>> fix it though). > >>> > >>> Should RFCs / protocols of this nature just come with something like a > >>> quickcheck model for their spec? Is anyone aware of prior art around > this > >>> sort of thing aside from Quvic/Volvo that I could draw from if I > wanted to > >>> fiddle in this arena? > >>> > >>> I'd think that the ideal situation involves an open source quickcheck > >>> implementation to test a given protocol implementation against at least > >>> some of the RFC, and a means to run the tests against potential > >>> servers/clients, with badges potentially showing the percentage of the > test > >>> that passes. This would allow economics to drive spec implementers > towards > >>> correctness, which would save countless engineer-hours spent figuring > out > >>> why the damn clients can't talk to the damn servers for a given spec. > >>> > >>> Thoughts? Pipe dream? "Silly child, see A, B, and C for the many > people > >>> who are already doing this?" > >>> > >>> -- > >>> Josh Adams > >>> > >>> _______________________________________________ > >>> 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 > > > - -- > James Aimonetti > > Lead Systems Architect > "If Dialyzer don't care, I don't care" > 2600HzPDX | http://2600hz.com > sip:james@REDACTED > tel:415.886.7905 > irc:mc_ @ freenode > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJX5D73AAoJENTKa+JPXCVg8SwH/jTe/EhqLBQc1b82rptahsuy > SL2dwQjzq6kxfzJquVE05t4yjjhI3GKaHoaeGkPMNF4Wq4Y9ZdWVOrIfyE1fHuxg > EltLgUq6OAjQeCYkQXNOTtcWzt6AJ8ZpKK9z9U7hydJL9NAs1IF6v2D/NjbvJ02H > OAlRLZzhqcN1nm+/yOPPqs9zBac5SR3YHK3bo8A5vlx5M+8jrI3SV6fe5cBXTbIF > CzVKmrlD3EZlGEYaDN1ssFDShv42CZJk4+2bvQnsJDJ4YRe7WqoDOJIhgcg92Tuo > ntiYR8nlMY+qzDWYjOZnpVNNUN5oudLUjmhCuLU5vGwkLB74Y+2YBwxbC7gabec= > =KvP6 > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Sep 23 03:54:23 2016 From: ok@REDACTED (ok@REDACTED) Date: Fri, 23 Sep 2016 13:54:23 +1200 Subject: [erlang-questions] Performance of type_to_type functions In-Reply-To: References: Message-ID: > integer_to_list >> integer_to_binary >> atom_to_binary >> ... > > > how about the performance of this type to type function? Compared with what? If you need such a conversion, what would you use instead? If you're seriously worried, write some benchmarks. From yueyoum@REDACTED Fri Sep 23 04:34:17 2016 From: yueyoum@REDACTED (=?UTF-8?B?5pyI5b+n6IyX?=) Date: Fri, 23 Sep 2016 10:34:17 +0800 Subject: [erlang-questions] How to specify a clear map type In-Reply-To: References: Message-ID: Thanks Magnus, I found that If I construct a map in the erl file, the dialyzer will find an type error. -module(xx). -export([find_value/2]). -type my_type() :: #{integer() := string()}. find_value(Key, _State) when is_atom(Key) -> State = #{1 => "abc", 2 => "def"}, find_value_1(Key, State). -spec find_value_1(atom(), my_type()) -> string(). find_value_1(Key, State) -> #{Key := Value} = State, Value. Checking whether the PLT /home/wang/.dialyzer_plt is up-to-date... yes > > Proceeding with analysis... > > xx.erl:14: Function find_value/2 has no local return > > xx.erl:19: Function find_value_1/2 has no local return > > xx.erl:20: The pattern #{Key:=Value} can never match the type #{1:=[97 | >> 98 | 99,...], 2:=[100 | 101 | 102,...]} > > done in 0m1.42s > > done (warnings were emitted) > > > But , if the map is not constructed in this erl file, dialyzer can not find any error. -module(xx). -export([find_value/2]). -type my_type() :: #{integer() := string()}. -spec find_value(atom(), my_type()) -> string(). find_value(Key, State) when is_atom(Key) -> find_value_1(Key, State). -spec find_value_1(atom(), my_type()) -> string(). find_value_1(Key, State) -> #{Key := Value} = State, Value. Checking whether the PLT /home/wang/.dialyzer_plt is up-to-date... yes > > Proceeding with analysis... done in 0m1.35s > > done (passed successfully) > > > 2016-09-23 7:01 GMT+08:00 Magnus L?ng : > On 2016-09-22 18:39, ??? wrote: > > According this document: http://erlang.org/doc/reference_manual/typespec. > html > > I can define a map type like this: > > -type my_type() :: #{integer() := string()}. > > > I have a map called State, it's type is `my_type`, key type is integer, > value type is string. > > -spec find_value(atom(), my_type()) -> string(). >> find_value(Key, State) when is_atom(Key) -> >> #{Key := Value} = State, >> Value. > > > > Using dialyzer analysis the file. nothing happens. > dialyzer say there is no error for this file. > > I know maps are dynamic, my_type() just meas this map must have a integer > key associated with a string value. > But not limit to add other type key and value in the map. > > My question is that Is it possible limit the map types of key and value ? > So dialyzer can find the match error in my program. > > > Actually, your type is already restricted in this way, and I'm surprised > your find_value example does not produce any warnings. Dialyzer should be > quite capable of finding the problem. Indeed, if we enforce the type of the > State argument in this (slightly ridiculous) way instead of using a type > specification, the problem *is* found: > > find_value(Key, State) -> > StateList = [{K, V} || {K, V} <- maps:to_list(State), > is_integer(K), is_list(V)], > find_value_1(Key, maps:from_list(StateList)). > > find_value_1(Key, State) when is_atom(Key) -> > #{Key := Value} = State, > Value. > > When I get some time over, I'll have a look at why your example does not > fail, but for now rest assured that your type syntax is correct and means > what you want it to mean. > > // Magnus > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- My GitHub https://github.com/yueyoum -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Fri Sep 23 05:18:29 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Thu, 22 Sep 2016 20:18:29 -0700 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On 09/22/2016 05:55 PM, Lo?c Hoguin wrote: > Examples are never a bad thing to have; at worst they provide no value > for the majority of people; If they make the documentation hard to read and understand, they're definitely a net negative. A web development buddy of mine and I were using some library whose documentation he thought was a _paragon_ of readability. The "documentation" took the form of a complete program that exercised _every_ part of the -somewhat large- library on the right half of the screen, and call-outs aligned with the lines that they commented on that provided bare-bones commentary on most (but not all) of the API calls on the left half of the screen. That was the _entirety_ of the documentation. It was _garbage_. Type-annotated (but otherwise auto-generated) Doxygen documentation would have been more useful. > Yes. Someone with no experience will always appreciate them. > > Not to mention that "sorted" in Erlang has a very specific meaning, > which is not defined at all in the documentation for lists:sort/1 A link back to section 8.11 of the Reference Manual User's Guide might be nice there. OTOH, I've never cared about the minutiae of how lists:sort/1 sorts. It has always just Done A Reasonable Thing(TM). Speaking of the User's Guide... -ideally- someone with no Erlang experience should first be reading the Reference Manual User's Guide along with the Getting Started Guide (or LYSE or something) to pick up the fundamentals, rather than the various module Reference Manuals. In my experience, reference manuals exist to quickly provide useful information to people who are already familiar with a language. They shouldn't be language primers, as primers serve another purpose and should be in another document. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nalundgaard@REDACTED Fri Sep 23 04:09:22 2016 From: nalundgaard@REDACTED (Nicholas Lundgaard) Date: Thu, 22 Sep 2016 21:09:22 -0500 Subject: [erlang-questions] ERL-263: leex conditionally counting line numbers incorrectly during tokenization Message-ID: <59A65367-93A9-4950-AC79-C9FA650B07DE@gmail.com> Hi all! My company, Alert Logic, co-maintains an open-source Erlang project for using AWS APIs, erlcloud: https://github.com/erlcloud/erlcloud One of the libraries it relies on is eini, for parsing AWS credential files (INI format): https://github.com/erlcloud/eini Because that project?s maintainer abandoned it, I?ve been looking at it recently with an eye to resolve some issues with it. One thing I noticed is that its unit test pass on OTP R16B03-1 and fail on OTP 17+ (I?ve tried 17.5, 18.3, and 19.0). The failures are caused by an inconsistent behavior in leex (or something it uses) that causes the line numbers to be stored incorrectly during tokenization. I?ve filed a bug report, ERL-263: https://bugs.erlang.org/browse/ERL-263 I wanted to call this to the members? attention; in part to see if my read of this issue is correct, and also to see if there is any possible workaround to it. The problem itself is mostly immaterial to us?it just means that the error output will (rarely) reference the wrong line number. I?m wondering, though, if there is some tweak I could make to the definition that would ameliorate or eliminate this problem. Thank you for your consideration. Regards, ?Nicholas Lundgaard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Fri Sep 23 06:22:02 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Fri, 23 Sep 2016 00:22:02 -0400 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <58833391-CA3B-43E8-AD9C-6F1760E6BAC0@writersglen.com> Hi Kenneth, No doubt your experience and knowledge of Erlang fills in much of what you need to make perfect sense of what you read in the Erlang docs. But I wish you could put yourself in noobie-mind. I've spent three years working alone and diligently so with help now and again from folks on this list to master enough Erlang to do a necessary job of work. I have bought, read, and re-read all of the published Erlang programming books. I've read Joe Armstrong's book at least six times and still learn from it every time I open it up. But I can't tell you how many hours I've lost trying to figure out how to use this function or that based on the Reference docs when an example or two might have cleared things up post haste. Perhaps I'm less intelligent than the average newcomer to Erlang. But I can say that as good as they are in many ways, I believe the docs can be better. Indeed, I confess that the descriptions of not a few functions, and even entire modules, leave me cross-eyed. Am I the only one? If I saw a healthy trend of newcomers becoming active in the Erlang community I wouldn't be as concerned. But I don't see it. I've made a modest proposal to address an issue noted by several folks on this thread. I'd welcome any other proposal and concrete action that make the docs more accessible to newcomers looking into Erlang. In my experience and judgement, there are just too many valuable but hidden gems in this wonderful language called Erlang. Wish I knew enough to shed light, but I don't. All the best, Lloyd Sent from my iPad > On Sep 22, 2016, at 11:18 PM, Kenneth Lakin wrote: > >> On 09/22/2016 05:55 PM, Lo?c Hoguin wrote: >> Examples are never a bad thing to have; at worst they provide no value >> for the majority of people; > > If they make the documentation hard to read and understand, they're > definitely a net negative. > > A web development buddy of mine and I were using some library whose > documentation he thought was a _paragon_ of readability. The > "documentation" took the form of a complete program that exercised > _every_ part of the -somewhat large- library on the right half of the > screen, and call-outs aligned with the lines that they commented on that > provided bare-bones commentary on most (but not all) of the API calls on > the left half of the screen. > > That was the _entirety_ of the documentation. It was _garbage_. > Type-annotated (but otherwise auto-generated) Doxygen documentation > would have been more useful. > >> Yes. Someone with no experience will always appreciate them. >> >> Not to mention that "sorted" in Erlang has a very specific meaning, >> which is not defined at all in the documentation for lists:sort/1 > > A link back to section 8.11 of the Reference Manual User's Guide might > be nice there. OTOH, I've never cared about the minutiae of how > lists:sort/1 sorts. It has always just Done A Reasonable Thing(TM). > > Speaking of the User's Guide... -ideally- someone with no Erlang > experience should first be reading the Reference Manual User's Guide > along with the Getting Started Guide (or LYSE or something) to pick up > the fundamentals, rather than the various module Reference Manuals. In > my experience, reference manuals exist to quickly provide useful > information to people who are already familiar with a language. They > shouldn't be language primers, as primers serve another purpose and > should be in another document. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Fri Sep 23 07:30:31 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 23 Sep 2016 17:30:31 +1200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <3787d0d6-c4f0-ae30-632b-e3632dd82c4e@cs.otago.ac.nz> On 23/09/16 3:18 PM, Kenneth Lakin wrote: > On 09/22/2016 05:55 PM, Lo?c Hoguin wrote: >> Examples are never a bad thing to have; at worst they provide no value >> for the majority of people; > > If they make the documentation hard to read and understand, they're > definitely a net negative. I can only say that I have found the occasional example in the Unix manual pages to be a lifesaver, and that the presence of examples in the R documentation has often made it straightforward to use something whose description was not particularly helpful. I suppose I can also say that "show me a list of places where this method is called" has been extremely informative when working on Smalltalk, even though those aren't *crafted* examples. Examples *instead* of documentation would be a bad thing. Examples *mixed in with* documentation can be distracting. So you have a library module. There are - source code - documentation - examples Thanks to the magic of hypertext, these things don't have to be in the same view. One reason for separating them is that somethings an example *has* to be an example of several things, so it's nice that it can be pointed to from several places, rather than duplicated. From nayibor@REDACTED Fri Sep 23 08:23:21 2016 From: nayibor@REDACTED (Nuku Ameyibor) Date: Fri, 23 Sep 2016 06:23:21 +0000 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <3787d0d6-c4f0-ae30-632b-e3632dd82c4e@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <3787d0d6-c4f0-ae30-632b-e3632dd82c4e@cs.otago.ac.nz> Message-ID: i agree with Lloyd . i also spent countless hours when i was learning erlang trying to understand some functions and how to use them . So you have a library module. > There are > - source code > - documentation > - examples > source code can be even more confusing for a beginner as it may be written in a very compact way that a beginner may not understand at that point in time although it may be crystal clear for others . documentation does not contain examples for most functions so you are still stuck . the maps module is one example of a module which would be very easy for a *newcomer* to use as all the functions have a short explanation followed by an example usage scenario . On Fri, Sep 23, 2016 at 5:30 AM, Richard A. O'Keefe wrote: > > > On 23/09/16 3:18 PM, Kenneth Lakin wrote: > >> On 09/22/2016 05:55 PM, Lo?c Hoguin wrote: >> >>> Examples are never a bad thing to have; at worst they provide no value >>> for the majority of people; >>> >> >> If they make the documentation hard to read and understand, they're >> definitely a net negative. >> > > I can only say that I have found the occasional example in the Unix > manual pages to be a lifesaver, and that the presence of examples in > the R documentation has often made it straightforward to use something > whose description was not particularly helpful. I suppose I can also > say that "show me a list of places where this method is called" has > been extremely informative when working on Smalltalk, even though those > aren't *crafted* examples. > > Examples *instead* of documentation would be a bad thing. > Examples *mixed in with* documentation can be distracting. > > So you have a library module. > There are > - source code > - documentation > - examples > Thanks to the magic of hypertext, these things don't have to be in the > same view. One reason for separating them is that somethings an > example *has* to be an example of several things, so it's nice that it > can be pointed to from several places, rather than duplicated. > > > _______________________________________________ > 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 Fri Sep 23 08:40:32 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 23 Sep 2016 08:40:32 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On 09/23/2016 05:18 AM, Kenneth Lakin wrote: > Speaking of the User's Guide... -ideally- someone with no Erlang > experience should first be reading the Reference Manual User's Guide > along with the Getting Started Guide (or LYSE or something) to pick up > the fundamentals, rather than the various module Reference Manuals. In > my experience, reference manuals exist to quickly provide useful > information to people who are already familiar with a language. They > shouldn't be language primers, as primers serve another purpose and > should be in another document. That's the thing: you have no control over what document people will read first. You also have no control over what people will *remember*. When first coming to the language, most people will forget/misremember/misunderstand most of what they read until they get some practice; and that's when a good function reference with all details and examples is helpful. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From pierrefenoll@REDACTED Fri Sep 23 09:33:30 2016 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Fri, 23 Sep 2016 09:33:30 +0200 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: There are a bunch of papers / thesis on this topic. I recommend the statem doc link I posted earlier. There's a talk from Quviq at latest SF Erlang Factory: https://m.youtube.com/watch?v=iW2J7Of8jsE Note that Quviq provides a paid CI service. My bet is a service that quickchecks a project's APIs would be worth good money. Here's a simple example of a PropEr statem: https://bitbucket.org/fenollp/kzp/src/7e6518dd33e1461cdecba22bc9e767aeb372d4d9/test/prop__user_auth.erl?at=master&fileviewer=file-view-default Please share your troubles / findings :) > On 22 Sep 2016, at 19:53, Andrew Berman wrote: > > Hey Pierre, > > How do you QuickCheck RESTful APIs? I'm a noobie with QuickCheck and using it with RESTful APIs would be really useful to me. Do you have any sample code or is there a tutorial anywhere? > > Thanks! > >> On Wed, Sep 21, 2016 at 10:58 PM Pierre Fenoll wrote: >> Have you tried using PropEr / Quickcheck statem? http://proper.softlab.ntua.gr/Tutorials/PropEr_testing_of_finite_state_machines.html >> PropEr is free & open source & I use it to quickcheck RESTfull APIs. >> >> >> >> Cheers, >> -- >> Pierre Fenoll >> >>> On 22 September 2016 at 05:45, Josh Adams wrote: >>> So I've been frustrated lately by the fact that Slack's IRC gateway isn't RFC 2812 compliant (https://github.com/bitwalker/exirc/issues/51) >>> >>> In dealing with this I wondered why the crap they needed an engineer to go through the spec as a result of their server's response to figure out that this was an issue (they've added it to their bug tracker, so I have some amount of faith it might get fixed eventually - for now I'll paper over the issue in the client which reduces the stress on them to actually fix it though). >>> >>> Should RFCs / protocols of this nature just come with something like a quickcheck model for their spec? Is anyone aware of prior art around this sort of thing aside from Quvic/Volvo that I could draw from if I wanted to fiddle in this arena? >>> >>> I'd think that the ideal situation involves an open source quickcheck implementation to test a given protocol implementation against at least some of the RFC, and a means to run the tests against potential servers/clients, with badges potentially showing the percentage of the test that passes. This would allow economics to drive spec implementers towards correctness, which would save countless engineer-hours spent figuring out why the damn clients can't talk to the damn servers for a given spec. >>> >>> Thoughts? Pipe dream? "Silly child, see A, B, and C for the many people who are already doing this?" >>> >>> -- >>> Josh Adams >>> >>> _______________________________________________ >>> 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 Fri Sep 23 09:53:34 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 23 Sep 2016 09:53:34 +0200 Subject: [erlang-questions] Quickcheck'ing a protocol In-Reply-To: References: Message-ID: On Thu, Sep 22, 2016 at 10:43 PM, Josh Adams wrote: > This all sounds amazing and like a thing I'd like to encourage the world > to adopt. The world seems to agree. A recent news article touches on the subject[0], where Jeanette Wing (and probably her research group) are working on building a formal model of TLS. There are a couple of viable avenues you can adopt. One of the more promising is to write down a formal specification from which you can derive test cases. But if constructed correctly, they can also be executed at the same time. Erlang isn't a nice vehicle for this since you are lack (Standard) ML style functors, but the ideas are certainly transferable. Because you can also execute the model, you can use it as a driver in a QuickCheck test case and make sure that some other implementation is correct w.r.t to the executable specification. The way to approach this kind of thing is to crawl before walking. Start out with a small ping-pong protocol which base64 encodes its queries and responses. Then show this correct and use that to build gradually more complex stuff. Most of the full quickcheck developments starts in a corner of the full system and then gradually extend themselves. Trying to attack a full system from day 1 is usually hard. Also, you have to learn some tricks in order to handle standard protocol problems. By targeting toys with those problems it is often easier to figure out how to handle them, before trying to do it on the full system. Model building is fun, but it takes the same thought process as when you are trying to solve an abstract math problem: the answer will come to you why you are doing other stuff, muddling on the question. [0] https://www.quantamagazine.org/20160920-formal-verification-creates-hacker-proof-code/ -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Sep 23 10:13:38 2016 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 23 Sep 2016 10:13:38 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: I have a few comments about the documentation: This answers a few question that keep arising, and has a few of my own suggestions. Q: Who was the documentation written for? A: Ericsson Internal usage The original documentation made the following assumptions - The readers would be internal Ericsson programmers who knew Erlang - If the programmers had a problem understanding things they would ask us directly So we favored a terse declarative style Q: How is the documentation structured A: It's all in XML The idea was that all documentation would be generated from the XML There are current about 1000 XML files containing about 10MB of text The XML sources are in the distribution source tree. So for example the documentation for lists.erl is in the file /lib/stdlib/doc/src/lists.xml ( is where the system was unpacked) Q: How is the documentation produced A: Programmatically Various programs munge the XML inputs (and the sources) trying to make web-sites and PDF We could use some help here - really - the PDF is produced with some XSLT magic and the web site with goodness knows what. So what's wrong and what could we do? 1) Things are not beautiful I agree - the documentation is not typographically beautiful Personally I like PDF - I took a look and found this: http://www.latextemplates.com/template/the-legrand-orange-book It would be nice to transform the documentation into this form for printing and reading 2) The HTML documentation could be improved and made more interactive I have at various times written 'erl_to_html' that makes HTML pages out of erlang - it would be nice to browse your own code, clicking on function names to follow the code or to unfold the documentation. On-line documentation can have things like type spec in hidden folds which open in place when you click on them. Or possibly a tiddly-wiki like interface. http://tiddlywiki.com/ might inspire a new interface 3) There is no official proof-reading quality control mechanism I tried on several occasions to hire a technical author - management always views this as a waste of money - so this never happened. Most of the documentation is written by people who are not native English speakers. They could use some help. By contract my Erlang book had - Me (who wrote it) - Dave Thomas (my editor) (he was great) - A Proof Reader (By proof reader I mead one of these super-human beings who can spot a spelling error at 10,000 meters from your text, while reading upside down by candle light - An Indexer (did you know there were professional Indexers?) - A typographer (who worried about https://en.wikipedia.org/wiki/Widows_and_orphans) Have you every heard *anybody* complaining about widows and orphans in the Erlang printed documentation? I had to rephrase several paragraphs to avoid nasty widows and orphans. 4) There are no examples I agree there should be zillions of examples. Rather than adding them to the existing XML tree I'd propose a new DTD for examples which could be cross-linked into the documentation. 5) There are no construction examples Examples show "the finished work" but not "how you got there" In my book I often shown really short functions in 10 lines or so of code. But I don't discuss how I got to those ten lines. I show the 10 lines and explain what each lines does. I do not explain how I wrote the first line - I might have googled a bit done some research. In a 50 line program I'll probably have tested it as I grew it - testing 10 lines at a time. How we grow programs from small seeds is not explained. 6) The barrier for entry for fixing a typo is HUGE If I see a typo (a simple spelling error) in the on-line documentation the barrier of entry for fixing it is HUGE (sorry for SHOUTING). Download the entire distribution - unpack (240 MBytes) find the typo (where the heck is it?) - fix it - make a push request .... Do I really have to download hundreds of Megabytes to fix a one character typo? I keep pointing people to the web site for "real world Haskell" http://book.realworldhaskell.org/read/functional-programming.html The barrier for entry to fixing a mistake in the text is minimal. I actually like the RWH model - the reader adds a comment, the author fixes the bug. When writing books I would not like other people fixing my typos, I want many eyes to help be find the typos - then I'll fix them? Why is this? Because I'm ultimately responsible for what I write - Sometimes (not often) I might want to totally rewrite a section based on a single typo. If somebody could figure out how to automate fixing typos it would be great. [the problem is to find the XML that needs to be edited, given that the error was found in a generated document - I guess if each paragraph has a hidden GUID <> it would be trivial] 7) The erlang mailing list has loads of examples The erlang mailing list has thousands of useful examples but they are not extracted, edited sorted and classified. There are issues of copyright and attribution here - but I think it would be useful to extract some of the better postings to this list and move them into the documentation tree. Making beautiful readable useful documentation is very difficult and needs love care and attention to detail - it's an unappreciated form of literature. On Fri, Sep 23, 2016 at 8:40 AM, Lo?c Hoguin wrote: > On 09/23/2016 05:18 AM, Kenneth Lakin wrote: >> >> Speaking of the User's Guide... -ideally- someone with no Erlang >> experience should first be reading the Reference Manual User's Guide >> along with the Getting Started Guide (or LYSE or something) to pick up >> the fundamentals, rather than the various module Reference Manuals. In >> my experience, reference manuals exist to quickly provide useful >> information to people who are already familiar with a language. They >> shouldn't be language primers, as primers serve another purpose and >> should be in another document. > > > That's the thing: you have no control over what document people will read > first. You also have no control over what people will *remember*. > > When first coming to the language, most people will > forget/misremember/misunderstand most of what they read until they get some > practice; and that's when a good function reference with all details and > examples is helpful. > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Fri Sep 23 10:23:50 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 23 Sep 2016 10:23:50 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: Hi! On Fri, Sep 23, 2016 at 10:13 AM, Joe Armstrong wrote: > If I see a typo (a simple spelling error) in the on-line documentation > the barrier of entry for fixing it is HUGE (sorry for SHOUTING). > > Download the entire distribution - unpack (240 MBytes) find the > typo (where the heck is it?) - fix it - make a push request .... > > Do I really have to download hundreds of Megabytes to fix a one > character typo? > Github allows you to make small corrections online, without downloading anything. If you don't already have a fork of the repo, it will be created and you will get an option to create a PR for the fix (commiters can commit directly to a branch). Just go to the file in the source tree and press the "Edit this file" button (the pen in the upper right corner). best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.behnke@REDACTED Fri Sep 23 10:36:50 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Fri, 23 Sep 2016 10:36:50 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: I would propose a position specific to the reference documentation: 8) Put the documentation in the source code. Use edoc (or similar new tool). This would not take a step in the direction of https://en.wikipedia.org/wiki/Literate_programming (which I think is a type of holy grail that stiving for is good, but reaching will not really help), but also put pressure on edoc to improve the presentation (pos 2 in Joe's list). But it would also help when the documentation is not sufficient to provide understanding: first you can look at the documentation website. Should that fail to provide understanding to the user, he or she has a clear system of going from docs for module X to source of module X and looking there. Much more daunting, but a clear escalation path. Also just grepping for phrases from the documentation is quick and to the point. And it should a precedent for 3rd party libraries. Java doc/ Doxygen are fairly good examples for wide spread adoption or integration into other tools. And it helps me write docs when I can still remember what the func actually does. Other Point: Joe, getting the OTP code drop from github is not a problem at all. one copy and paste on github website, two clicks in eclipse. Voila: manual work done. BTW: This does not contradict your point on user-comments on the docs website. php.net was pointed out in this discussion before. The best code examples there are in the user comments. mfg lutz Am 23.09.2016 um 10:13 schrieb Joe Armstrong: > I have a few comments about the documentation: > > This answers a few question that keep arising, and has a few of my own > suggestions. > > Q: Who was the documentation written for? > > A: Ericsson Internal usage > > The original documentation made the following assumptions > > - The readers would be internal Ericsson programmers who knew Erlang > - If the programmers had a problem understanding things they would ask > us directly > > So we favored a terse declarative style > > Q: How is the documentation structured > A: It's all in XML > > The idea was that all documentation would be generated from the XML > There are current about 1000 XML files containing about 10MB of text > > The XML sources are in the distribution source tree. > So for example the documentation for lists.erl is in the file > /lib/stdlib/doc/src/lists.xml ( is where the system was unpacked) > > Q: How is the documentation produced > A: Programmatically > > Various programs munge the XML inputs (and the sources) trying to make > web-sites and PDF > > We could use some help here - really - the PDF is produced with > some XSLT magic > and the web site with goodness knows what. > > So what's wrong and what could we do? > > 1) Things are not beautiful > > I agree - the documentation is not typographically beautiful > > Personally I like PDF - I took a look and found this: > > http://www.latextemplates.com/template/the-legrand-orange-book > > It would be nice to transform the documentation into this form > for printing and reading > > 2) The HTML documentation could be improved and made more interactive > > I have at various times written 'erl_to_html' that makes HTML pages out of > erlang - it would be nice to browse your own code, clicking on function names > to follow the code or to unfold the documentation. > > On-line documentation can have things like type spec in hidden folds > which open in place when you click on them. Or possibly a tiddly-wiki like > interface. > > http://tiddlywiki.com/ might inspire a new interface > > 3) There is no official proof-reading quality control mechanism > > I tried on several occasions to hire a technical author - management always > views this as a waste of money - so this never happened. > > Most of the documentation is written by people who are not > native English speakers. They could use some help. > > By contract my Erlang book had > > - Me (who wrote it) > - Dave Thomas (my editor) (he was great) > - A Proof Reader (By proof reader I mead one of these super-human beings > who can spot a spelling error at 10,000 meters from your text, > while reading upside down by candle light > - An Indexer (did you know there were professional Indexers?) > - A typographer (who worried about > https://en.wikipedia.org/wiki/Widows_and_orphans) > > Have you every heard *anybody* complaining about widows and orphans > in the Erlang printed documentation? I had to rephrase several > paragraphs to avoid nasty widows and orphans. > > 4) There are no examples > > I agree there should be zillions of examples. > > Rather than adding them to the existing XML tree I'd propose a new > DTD for examples which could be cross-linked into the > documentation. > > > 5) There are no construction examples > > Examples show "the finished work" but not "how you got there" > > In my book I often shown really short functions in 10 lines or so > of code. But I don't discuss how I got to those ten lines. > > I show the 10 lines and explain what each lines does. > > I do not explain how I wrote the first line - I might have googled > a bit done some research. In a 50 line program I'll probably have > tested it as I grew it - testing 10 lines at a time. > > How we grow programs from small seeds is not explained. > > 6) The barrier for entry for fixing a typo is HUGE > > If I see a typo (a simple spelling error) in the on-line documentation > the barrier of entry for fixing it is HUGE (sorry for SHOUTING). > > Download the entire distribution - unpack (240 MBytes) find the > typo (where the heck is it?) - fix it - make a push request .... > > Do I really have to download hundreds of Megabytes to fix a one > character typo? > > I keep pointing people to the web site for "real world Haskell" > http://book.realworldhaskell.org/read/functional-programming.html > > The barrier for entry to fixing a mistake in the text is minimal. > I actually like the RWH model - the reader adds a comment, the author fixes > the bug. > > When writing books I would not like other people fixing my typos, I > want many eyes to help be find the typos - then I'll fix them? Why > is this? Because I'm ultimately responsible for what I write - > Sometimes (not often) I might want to totally rewrite a section > based on a single typo. > > If somebody could figure out how to automate fixing typos it would be great. > [the problem is to find the XML that needs to be edited, given that the error > was found in a generated document - I guess if each paragraph has > a hidden GUID > <> it would be trivial] > > > > > 7) The erlang mailing list has loads of examples > > The erlang mailing list has thousands of useful examples > but they are not extracted, edited sorted and classified. > > There are issues of copyright and attribution here - but I think > it would be useful to extract some of the better postings to this list > and move them into the documentation tree. > > > Making beautiful readable useful documentation is very difficult and > needs love care and attention to detail - it's an unappreciated form > of literature. > > On Fri, Sep 23, 2016 at 8:40 AM, Lo?c Hoguin wrote: >> On 09/23/2016 05:18 AM, Kenneth Lakin wrote: >>> >>> Speaking of the User's Guide... -ideally- someone with no Erlang >>> experience should first be reading the Reference Manual User's Guide >>> along with the Getting Started Guide (or LYSE or something) to pick up >>> the fundamentals, rather than the various module Reference Manuals. In >>> my experience, reference manuals exist to quickly provide useful >>> information to people who are already familiar with a language. They >>> shouldn't be language primers, as primers serve another purpose and >>> should be in another document. >> >> >> That's the thing: you have no control over what document people will read >> first. You also have no control over what people will *remember*. >> >> When first coming to the language, most people will >> forget/misremember/misunderstand most of what they read until they get some >> practice; and that's when a good function reference with all details and >> examples is helpful. >> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> Author of The Erlanger Playbook, >> A book about software development using Erlang >> _______________________________________________ >> 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 > -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany From essen@REDACTED Fri Sep 23 11:17:19 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 23 Sep 2016 11:17:19 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On 09/23/2016 10:36 AM, Lutz Behnke wrote: > I would propose a position specific to the reference documentation: > > 8) Put the documentation in the source code. Use edoc (or similar new > tool). And I would strongly advise against that. It may sound like a good idea from a programmer's perspective, but it would make the life of any writer, editor, typesetter and others difficult. Then there's the finer issues: * Your documentation goes from everything in one place to small chunks interspersed here and there in the source files * It is not obvious what content the documentation will have until you generate it * Features like edoc's use of -spec declarations are not helpful; there is often a difference between what a function allows (the spec) and what is documented publicly (the doc) * This tends to make the source code the authority rather than the documentation, yet people write code against documentation so extra care should be taken to make it usable without looking at the source. It's much harder to do this when it's just next to the source * Etc. Personally I consider projects that only have doc comments to have no documentation at all. If the documentation is in the source I might as well just open the source files, I'll be sure to have up to date information there since (doc) comments tend to lag behind. Doc comments are the lazy programmer's solution. There's plenty of formats for writing documentation, I'd advise everyone to learn one or two. OTP uses docbook for better or worse. I personally use Asciidoc (which generates docbook and from there a variety of formats). There's various other formats each with their strengths and weaknesses, and most of them generate docbook at some point. I know full well writing documentation is hard. But it's worth doing extra efforts to get a great result. FYI I am currently working on improving the Cowboy function reference. My tentative currently looks similar to this for "man cowboy:start_clear": https://gist.github.com/essen/3affa1c8e7805a7dc867156b03c1854f - in HTML/PDF form it would of course have syntax highlighting, proper links and so on. And this brings us back to one of my points: the *content* is what matters. And it's a lot harder to focus on that content when this content is scattered in a zillion source files. Cheers, -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From lutz.behnke@REDACTED Fri Sep 23 11:43:10 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Fri, 23 Sep 2016 11:43:10 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: All your points are true. But unless the developer is also gifted with far above average discipline _and_ the ability to write good documentation, your approach does not result in good documentation. As Joe pointed out, management does not place great value in documentation specialists, nor is it a developers skill in high regard in most organisations. In my personal experience, even university level education is aimed against it ("..auto-testing, style-checking, documentation, version control, what else? We are teaching programming! For the rest there is no time!"). Given those preconditions, I think the OTP team has done a stellar job. Focus any resources of writers, editors, typesetters, etc. on providing good tutorials and user guides. Get new people riding the train before they have to dive into the reference material. To the trained reader, the resulting code is at least as obvious as XML source. You will have a generate HTML and PDF for both methods. But most importantly, when the source changes, there is at least some chance, that the documentation will be fixed as well. Or at least marked as incorrect. Bad, but better than docs and behavior obviously contradicting themselves. I have written docs in man/nroff, info, have submitted small patches to the RPM manual in docbook and usually write anything longer than a single page in LaTeX. But still find the mixing of code and documentation to generate the most helpfull information for the user in the absence of a team of technical writers (or source authors that are also able to write good documentation). mfg lutz Am 23.09.2016 um 11:17 schrieb Lo?c Hoguin: > On 09/23/2016 10:36 AM, Lutz Behnke wrote: >> I would propose a position specific to the reference documentation: >> >> 8) Put the documentation in the source code. Use edoc (or similar new >> tool). > > And I would strongly advise against that. > > It may sound like a good idea from a programmer's perspective, but it > would make the life of any writer, editor, typesetter and others > difficult. Then there's the finer issues: > > * Your documentation goes from everything in one place to small chunks > interspersed here and there in the source files > * It is not obvious what content the documentation will have until you > generate it > * Features like edoc's use of -spec declarations are not helpful; there > is often a difference between what a function allows (the spec) and what > is documented publicly (the doc) > * This tends to make the source code the authority rather than the > documentation, yet people write code against documentation so extra care > should be taken to make it usable without looking at the source. It's > much harder to do this when it's just next to the source > * Etc. > > Personally I consider projects that only have doc comments to have no > documentation at all. If the documentation is in the source I might as > well just open the source files, I'll be sure to have up to date > information there since (doc) comments tend to lag behind. > > Doc comments are the lazy programmer's solution. There's plenty of > formats for writing documentation, I'd advise everyone to learn one or > two. OTP uses docbook for better or worse. I personally use Asciidoc > (which generates docbook and from there a variety of formats). There's > various other formats each with their strengths and weaknesses, and most > of them generate docbook at some point. > > I know full well writing documentation is hard. But it's worth doing > extra efforts to get a great result. > > FYI I am currently working on improving the Cowboy function reference. > My tentative currently looks similar to this for "man > cowboy:start_clear": > https://gist.github.com/essen/3affa1c8e7805a7dc867156b03c1854f - in > HTML/PDF form it would of course have syntax highlighting, proper links > and so on. > > And this brings us back to one of my points: the *content* is what > matters. And it's a lot harder to focus on that content when this > content is scattered in a zillion source files. > > Cheers, > -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany From essen@REDACTED Fri Sep 23 12:02:57 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 23 Sep 2016 12:02:57 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <2e2783d3-8b58-bd52-6a4a-f75622a61029@ninenines.eu> I'll agree to disagree. I'll comment on one point though: On 09/23/2016 11:43 AM, Lutz Behnke wrote: > All your points are true. But unless the developer is also gifted with > far above average discipline _and_ the ability to write good > documentation, your approach does not result in good documentation. This is no gift, this is learnable skills and I would argue the first step to discipline yourself is to separate code and documentation; and the second step is to write or update the documentation before any code is written. As far as users are concerned, your documentation is your program, not the code. The code is for the developers of the program and the machines. Therefore what you really need to get right for your users is the documentation. It's different for internal libraries that have no direct users except the development team, and those are a lot more common than public libraries, which is probably why documentation is held in such a low regard. And perhaps doc comments are more than enough for that kind of project. But for libraries used by thousands of people or more? You definitely should spare no effort. Learn how to write great documentation. Iterate until you get something great. Even small improvements will end up having a huge impact over all users. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From erlang@REDACTED Fri Sep 23 12:45:39 2016 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 23 Sep 2016 12:45:39 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On Fri, Sep 23, 2016 at 10:23 AM, Vlad Dumitrescu wrote: > Hi! > > On Fri, Sep 23, 2016 at 10:13 AM, Joe Armstrong wrote: >> >> If I see a typo (a simple spelling error) in the on-line documentation >> the barrier of entry for fixing it is HUGE (sorry for SHOUTING). >> >> Download the entire distribution - unpack (240 MBytes) find the >> typo (where the heck is it?) - fix it - make a push request .... >> >> Do I really have to download hundreds of Megabytes to fix a one >> character typo? > > > Github allows you to make small corrections online, without downloading > anything. If you don't already have a fork of the repo, it will be created > and you will get an option to create a PR for the fix (commiters can commit > directly to a branch). Can my dearly beloved wife do this? Helen is *very* good at spelling and has found many typos in my drafts (bless her) - but she's never heard of github - and thinks that a fork is something you eat food with .. > Just go to the file in the source tree and press the "Edit this file" button > (the pen in the upper right corner). "Just" - if you can find the file in the source tree that is /Joe > > best regards, > Vlad > From erlang@REDACTED Fri Sep 23 12:51:29 2016 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 23 Sep 2016 12:51:29 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On Fri, Sep 23, 2016 at 10:36 AM, Lutz Behnke wrote: > I would propose a position specific to the reference documentation: > > 8) Put the documentation in the source code. Use edoc (or similar new tool). > > This would not take a step in the direction of > https://en.wikipedia.org/wiki/Literate_programming (which I think is a type > of holy grail that stiving for is good, but reaching will not really help), > but also put pressure on edoc to improve the presentation (pos 2 in Joe's > list). > > But it would also help when the documentation is not sufficient to provide > understanding: first you can look at the documentation website. Should that > fail to provide understanding to the user, he or she has a clear system of > going from docs for module X to source of module X and looking there. Much > more daunting, but a clear escalation path. Also just grepping for phrases > from the documentation is quick and to the point. > > And it should a precedent for 3rd party libraries. Java doc/ Doxygen are > fairly good examples for wide spread adoption or integration into other > tools. And it helps me write docs when I can still remember what the func > actually does. > > Other Point: Joe, getting the OTP code drop from github is not a problem at > all. one copy and paste on github website, two clicks in eclipse. Voila: > manual work done. Uuugh - I have to install and learn how to use Eclipse I have to know what github is. The wikipedia has a low barrier for entry - if you see a spelling mistake on a web page fixing it should be as easy as right clicking the mouse on the word typing a correction and hitting "send" I tried Eclipse once and was horrified - /Joe > BTW: This does not contradict your point on user-comments on the docs > website. php.net was pointed out in this discussion before. The best code > examples there are in the user comments. So make it drop dead easy to add comments - no sign in - no github no eclipse - no build system - no emacs - no vi - no source code tree Just point - click - add /Joe > > mfg lutz > > > Am 23.09.2016 um 10:13 schrieb Joe Armstrong: >> >> I have a few comments about the documentation: >> >> This answers a few question that keep arising, and has a few of my own >> suggestions. >> >> Q: Who was the documentation written for? >> >> A: Ericsson Internal usage >> >> The original documentation made the following assumptions >> >> - The readers would be internal Ericsson programmers who knew Erlang >> - If the programmers had a problem understanding things they would ask >> us directly >> >> So we favored a terse declarative style >> >> Q: How is the documentation structured >> A: It's all in XML >> >> The idea was that all documentation would be generated from the XML >> There are current about 1000 XML files containing about 10MB of text >> >> The XML sources are in the distribution source tree. >> So for example the documentation for lists.erl is in the file >> /lib/stdlib/doc/src/lists.xml ( is where the system was >> unpacked) >> >> Q: How is the documentation produced >> A: Programmatically >> >> Various programs munge the XML inputs (and the sources) trying to make >> web-sites and PDF >> >> We could use some help here - really - the PDF is produced with >> some XSLT magic >> and the web site with goodness knows what. >> >> So what's wrong and what could we do? >> >> 1) Things are not beautiful >> >> I agree - the documentation is not typographically beautiful >> >> Personally I like PDF - I took a look and found this: >> >> http://www.latextemplates.com/template/the-legrand-orange-book >> >> It would be nice to transform the documentation into this form >> for printing and reading >> >> 2) The HTML documentation could be improved and made more interactive >> >> I have at various times written 'erl_to_html' that makes HTML pages out >> of >> erlang - it would be nice to browse your own code, clicking on function >> names >> to follow the code or to unfold the documentation. >> >> On-line documentation can have things like type spec in hidden folds >> which open in place when you click on them. Or possibly a tiddly-wiki >> like >> interface. >> >> http://tiddlywiki.com/ might inspire a new interface >> >> 3) There is no official proof-reading quality control mechanism >> >> I tried on several occasions to hire a technical author - management >> always >> views this as a waste of money - so this never happened. >> >> Most of the documentation is written by people who are not >> native English speakers. They could use some help. >> >> By contract my Erlang book had >> >> - Me (who wrote it) >> - Dave Thomas (my editor) (he was great) >> - A Proof Reader (By proof reader I mead one of these super-human >> beings >> who can spot a spelling error at 10,000 meters from your text, >> while reading upside down by candle light >> - An Indexer (did you know there were professional Indexers?) >> - A typographer (who worried about >> https://en.wikipedia.org/wiki/Widows_and_orphans) >> >> Have you every heard *anybody* complaining about widows and orphans >> in the Erlang printed documentation? I had to rephrase several >> paragraphs to avoid nasty widows and orphans. >> >> 4) There are no examples >> >> I agree there should be zillions of examples. >> >> Rather than adding them to the existing XML tree I'd propose a new >> DTD for examples which could be cross-linked into the >> documentation. >> >> >> 5) There are no construction examples >> >> Examples show "the finished work" but not "how you got there" >> >> In my book I often shown really short functions in 10 lines or so >> of code. But I don't discuss how I got to those ten lines. >> >> I show the 10 lines and explain what each lines does. >> >> I do not explain how I wrote the first line - I might have googled >> a bit done some research. In a 50 line program I'll probably have >> tested it as I grew it - testing 10 lines at a time. >> >> How we grow programs from small seeds is not explained. >> >> 6) The barrier for entry for fixing a typo is HUGE >> >> If I see a typo (a simple spelling error) in the on-line documentation >> the barrier of entry for fixing it is HUGE (sorry for SHOUTING). >> >> Download the entire distribution - unpack (240 MBytes) find the >> typo (where the heck is it?) - fix it - make a push request .... >> >> Do I really have to download hundreds of Megabytes to fix a one >> character typo? >> >> I keep pointing people to the web site for "real world Haskell" >> http://book.realworldhaskell.org/read/functional-programming.html >> >> The barrier for entry to fixing a mistake in the text is minimal. >> I actually like the RWH model - the reader adds a comment, the author >> fixes >> the bug. >> >> When writing books I would not like other people fixing my typos, I >> want many eyes to help be find the typos - then I'll fix them? Why >> is this? Because I'm ultimately responsible for what I write - >> Sometimes (not often) I might want to totally rewrite a section >> based on a single typo. >> >> If somebody could figure out how to automate fixing typos it would be >> great. >> [the problem is to find the XML that needs to be edited, given that the >> error >> was found in a generated document - I guess if each paragraph has >> a hidden GUID >> <> it would be trivial] >> >> >> >> >> 7) The erlang mailing list has loads of examples >> >> The erlang mailing list has thousands of useful examples >> but they are not extracted, edited sorted and classified. >> >> There are issues of copyright and attribution here - but I think >> it would be useful to extract some of the better postings to this list >> and move them into the documentation tree. >> >> >> Making beautiful readable useful documentation is very difficult and >> needs love care and attention to detail - it's an unappreciated form >> of literature. >> >> On Fri, Sep 23, 2016 at 8:40 AM, Lo?c Hoguin wrote: >>> >>> On 09/23/2016 05:18 AM, Kenneth Lakin wrote: >>>> >>>> >>>> Speaking of the User's Guide... -ideally- someone with no Erlang >>>> experience should first be reading the Reference Manual User's Guide >>>> along with the Getting Started Guide (or LYSE or something) to pick up >>>> the fundamentals, rather than the various module Reference Manuals. In >>>> my experience, reference manuals exist to quickly provide useful >>>> information to people who are already familiar with a language. They >>>> shouldn't be language primers, as primers serve another purpose and >>>> should be in another document. >>> >>> >>> >>> That's the thing: you have no control over what document people will read >>> first. You also have no control over what people will *remember*. >>> >>> When first coming to the language, most people will >>> forget/misremember/misunderstand most of what they read until they get >>> some >>> practice; and that's when a good function reference with all details and >>> examples is helpful. >>> >>> >>> -- >>> Lo?c Hoguin >>> http://ninenines.eu >>> Author of The Erlanger Playbook, >>> A book about software development using Erlang >>> _______________________________________________ >>> 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 >> > > -- > Lutz Behnke > Hochschule f?r Angewandte Wissenschaften Hamburg, > Labor f?r Allgemeine Informatik, > > phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED > fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage > Berliner Tor 7, 20099 Hamburg, Germany > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Fri Sep 23 12:59:02 2016 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 23 Sep 2016 12:59:02 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <2e2783d3-8b58-bd52-6a4a-f75622a61029@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <2e2783d3-8b58-bd52-6a4a-f75622a61029@ninenines.eu> Message-ID: On Fri, Sep 23, 2016 at 12:02 PM, Lo?c Hoguin wrote: > I'll agree to disagree. I'll comment on one point though: > > On 09/23/2016 11:43 AM, Lutz Behnke wrote: >> >> All your points are true. But unless the developer is also gifted with >> far above average discipline _and_ the ability to write good >> documentation, your approach does not result in good documentation. > > > This is no gift, this is learnable skills and I would argue the first step > to discipline yourself is to separate code and documentation; and the second > step is to write or update the documentation before any code is written. Yes - writing is a learnable skill. I was crap at writing English in school. My spelling was terrible, punctuation non-existent. It took me 4 books to get to the point where I could say that I was good at writing. Nothing comes for free - the code I write, I write, then throw away then rewrite and throw away until it is beautiful. Same with English - write throw away - rewrite. Write more than you need and throw away the worse paragraphs - this emphasises what is left. After ten year you get good at it. > As far as users are concerned, your documentation is your program, not the > code. The code is for the developers of the program and the machines. > Therefore what you really need to get right for your users is the > documentation. If the programmers need to read the code to understand what your program does, then you have failed to write good documentation. > > It's different for internal libraries that have no direct users except the > development team, and those are a lot more common than public libraries, > which is probably why documentation is held in such a low regard. And > perhaps doc comments are more than enough for that kind of project. > > But for libraries used by thousands of people or more? You definitely should > spare no effort. Learn how to write great documentation. Iterate until you > get something great. Even small improvements will end up having a huge > impact over all users. Yes ^ 1000 The code (if you can understand it) tells the machine what to do. The documentation tells the reader what the program is *supposed* to do. Since the two are not usually the same it's a good idea to have some documentation that tells the poor sod who wants to use your code what it's supposed to do. /Joe > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lutz.behnke@REDACTED Fri Sep 23 13:39:05 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Fri, 23 Sep 2016 13:39:05 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <9a859632-06ac-a4df-4f95-65bc79f42068@informatik.haw-hamburg.de> Arrrgg! What have I done? Joe, please _do_not_ install Eclipse. It will lead you down a path of pain and the acceptance of continued unexpected behavoir in a bloated monster! You where rightly horrified and are likely to still be. Unfortunately it is the only IDE that a) has support for all the languages that I have to converse in concurrently and b) has pretty buttons to help me rember how to activate specific functions. If you start with a new tool I would advise something more lightweight. Atom looks good, but I do not have the time to invest in learning a new IDE. +1 (at least) on the low barrier comment think. mfg lutz Am 23.09.2016 um 12:51 schrieb Joe Armstrong: > On Fri, Sep 23, 2016 at 10:36 AM, Lutz Behnke > wrote: >> I would propose a position specific to the reference documentation: >> >> 8) Put the documentation in the source code. Use edoc (or similar new tool). >> >> This would not take a step in the direction of >> https://en.wikipedia.org/wiki/Literate_programming (which I think is a type >> of holy grail that stiving for is good, but reaching will not really help), >> but also put pressure on edoc to improve the presentation (pos 2 in Joe's >> list). >> >> But it would also help when the documentation is not sufficient to provide >> understanding: first you can look at the documentation website. Should that >> fail to provide understanding to the user, he or she has a clear system of >> going from docs for module X to source of module X and looking there. Much >> more daunting, but a clear escalation path. Also just grepping for phrases >> from the documentation is quick and to the point. >> >> And it should a precedent for 3rd party libraries. Java doc/ Doxygen are >> fairly good examples for wide spread adoption or integration into other >> tools. And it helps me write docs when I can still remember what the func >> actually does. >> >> Other Point: Joe, getting the OTP code drop from github is not a problem at >> all. one copy and paste on github website, two clicks in eclipse. Voila: >> manual work done. > > Uuugh - I have to install and learn how to use Eclipse > I have to know what github is. > > The wikipedia has a low barrier for entry - if you see a spelling > mistake on a web page fixing it should be as easy as right clicking > the mouse on the word > typing a correction and hitting "send" > > I tried Eclipse once and was horrified - > > /Joe > > >> BTW: This does not contradict your point on user-comments on the docs >> website. php.net was pointed out in this discussion before. The best code >> examples there are in the user comments. > > So make it drop dead easy to add comments - no sign in - no github > no eclipse - no build system - no emacs - no vi - no source code tree > > Just point - click - add > > /Joe > >> >> mfg lutz >> >> >> Am 23.09.2016 um 10:13 schrieb Joe Armstrong: >>> >>> I have a few comments about the documentation: >>> >>> This answers a few question that keep arising, and has a few of my own >>> suggestions. >>> >>> Q: Who was the documentation written for? >>> >>> A: Ericsson Internal usage >>> >>> The original documentation made the following assumptions >>> >>> - The readers would be internal Ericsson programmers who knew Erlang >>> - If the programmers had a problem understanding things they would ask >>> us directly >>> >>> So we favored a terse declarative style >>> >>> Q: How is the documentation structured >>> A: It's all in XML >>> >>> The idea was that all documentation would be generated from the XML >>> There are current about 1000 XML files containing about 10MB of text >>> >>> The XML sources are in the distribution source tree. >>> So for example the documentation for lists.erl is in the file >>> /lib/stdlib/doc/src/lists.xml ( is where the system was >>> unpacked) >>> >>> Q: How is the documentation produced >>> A: Programmatically >>> >>> Various programs munge the XML inputs (and the sources) trying to make >>> web-sites and PDF >>> >>> We could use some help here - really - the PDF is produced with >>> some XSLT magic >>> and the web site with goodness knows what. >>> >>> So what's wrong and what could we do? >>> >>> 1) Things are not beautiful >>> >>> I agree - the documentation is not typographically beautiful >>> >>> Personally I like PDF - I took a look and found this: >>> >>> http://www.latextemplates.com/template/the-legrand-orange-book >>> >>> It would be nice to transform the documentation into this form >>> for printing and reading >>> >>> 2) The HTML documentation could be improved and made more interactive >>> >>> I have at various times written 'erl_to_html' that makes HTML pages out >>> of >>> erlang - it would be nice to browse your own code, clicking on function >>> names >>> to follow the code or to unfold the documentation. >>> >>> On-line documentation can have things like type spec in hidden folds >>> which open in place when you click on them. Or possibly a tiddly-wiki >>> like >>> interface. >>> >>> http://tiddlywiki.com/ might inspire a new interface >>> >>> 3) There is no official proof-reading quality control mechanism >>> >>> I tried on several occasions to hire a technical author - management >>> always >>> views this as a waste of money - so this never happened. >>> >>> Most of the documentation is written by people who are not >>> native English speakers. They could use some help. >>> >>> By contract my Erlang book had >>> >>> - Me (who wrote it) >>> - Dave Thomas (my editor) (he was great) >>> - A Proof Reader (By proof reader I mead one of these super-human >>> beings >>> who can spot a spelling error at 10,000 meters from your text, >>> while reading upside down by candle light >>> - An Indexer (did you know there were professional Indexers?) >>> - A typographer (who worried about >>> https://en.wikipedia.org/wiki/Widows_and_orphans) >>> >>> Have you every heard *anybody* complaining about widows and orphans >>> in the Erlang printed documentation? I had to rephrase several >>> paragraphs to avoid nasty widows and orphans. >>> >>> 4) There are no examples >>> >>> I agree there should be zillions of examples. >>> >>> Rather than adding them to the existing XML tree I'd propose a new >>> DTD for examples which could be cross-linked into the >>> documentation. >>> >>> >>> 5) There are no construction examples >>> >>> Examples show "the finished work" but not "how you got there" >>> >>> In my book I often shown really short functions in 10 lines or so >>> of code. But I don't discuss how I got to those ten lines. >>> >>> I show the 10 lines and explain what each lines does. >>> >>> I do not explain how I wrote the first line - I might have googled >>> a bit done some research. In a 50 line program I'll probably have >>> tested it as I grew it - testing 10 lines at a time. >>> >>> How we grow programs from small seeds is not explained. >>> >>> 6) The barrier for entry for fixing a typo is HUGE >>> >>> If I see a typo (a simple spelling error) in the on-line documentation >>> the barrier of entry for fixing it is HUGE (sorry for SHOUTING). >>> >>> Download the entire distribution - unpack (240 MBytes) find the >>> typo (where the heck is it?) - fix it - make a push request .... >>> >>> Do I really have to download hundreds of Megabytes to fix a one >>> character typo? >>> >>> I keep pointing people to the web site for "real world Haskell" >>> http://book.realworldhaskell.org/read/functional-programming.html >>> >>> The barrier for entry to fixing a mistake in the text is minimal. >>> I actually like the RWH model - the reader adds a comment, the author >>> fixes >>> the bug. >>> >>> When writing books I would not like other people fixing my typos, I >>> want many eyes to help be find the typos - then I'll fix them? Why >>> is this? Because I'm ultimately responsible for what I write - >>> Sometimes (not often) I might want to totally rewrite a section >>> based on a single typo. >>> >>> If somebody could figure out how to automate fixing typos it would be >>> great. >>> [the problem is to find the XML that needs to be edited, given that the >>> error >>> was found in a generated document - I guess if each paragraph has >>> a hidden GUID >>> <> it would be trivial] >>> >>> >>> >>> >>> 7) The erlang mailing list has loads of examples >>> >>> The erlang mailing list has thousands of useful examples >>> but they are not extracted, edited sorted and classified. >>> >>> There are issues of copyright and attribution here - but I think >>> it would be useful to extract some of the better postings to this list >>> and move them into the documentation tree. >>> >>> >>> Making beautiful readable useful documentation is very difficult and >>> needs love care and attention to detail - it's an unappreciated form >>> of literature. >>> >>> On Fri, Sep 23, 2016 at 8:40 AM, Lo?c Hoguin wrote: >>>> >>>> On 09/23/2016 05:18 AM, Kenneth Lakin wrote: >>>>> >>>>> >>>>> Speaking of the User's Guide... -ideally- someone with no Erlang >>>>> experience should first be reading the Reference Manual User's Guide >>>>> along with the Getting Started Guide (or LYSE or something) to pick up >>>>> the fundamentals, rather than the various module Reference Manuals. In >>>>> my experience, reference manuals exist to quickly provide useful >>>>> information to people who are already familiar with a language. They >>>>> shouldn't be language primers, as primers serve another purpose and >>>>> should be in another document. >>>> >>>> >>>> >>>> That's the thing: you have no control over what document people will read >>>> first. You also have no control over what people will *remember*. >>>> >>>> When first coming to the language, most people will >>>> forget/misremember/misunderstand most of what they read until they get >>>> some >>>> practice; and that's when a good function reference with all details and >>>> examples is helpful. >>>> >>>> >>>> -- >>>> Lo?c Hoguin >>>> http://ninenines.eu >>>> Author of The Erlanger Playbook, >>>> A book about software development using Erlang >>>> _______________________________________________ >>>> 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 >>> >> >> -- >> Lutz Behnke >> Hochschule f?r Angewandte Wissenschaften Hamburg, >> Labor f?r Allgemeine Informatik, >> >> phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED >> fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage >> Berliner Tor 7, 20099 Hamburg, Germany >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany From vladdu55@REDACTED Fri Sep 23 15:21:18 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 23 Sep 2016 15:21:18 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: Hi Joe, On Fri, Sep 23, 2016 at 12:45 PM, Joe Armstrong wrote: > On Fri, Sep 23, 2016 at 10:23 AM, Vlad Dumitrescu > wrote: > > Hi! > > > > On Fri, Sep 23, 2016 at 10:13 AM, Joe Armstrong > wrote: > >> > >> If I see a typo (a simple spelling error) in the on-line documentation > >> the barrier of entry for fixing it is HUGE (sorry for SHOUTING). > >> > >> Download the entire distribution - unpack (240 MBytes) find the > >> typo (where the heck is it?) - fix it - make a push request .... > >> > >> Do I really have to download hundreds of Megabytes to fix a one > >> character typo? > > > > > > Github allows you to make small corrections online, without downloading > > anything. If you don't already have a fork of the repo, it will be > created > > and you will get an option to create a PR for the fix (commiters can > commit > > directly to a branch). > > Can my dearly beloved wife do this? > > Helen is *very* good at spelling and has found many typos in my > drafts (bless her) - but she's never heard of github - and thinks that > a fork is something you eat food with .. > > > Just go to the file in the source tree and press the "Edit this file" > button > > (the pen in the upper right corner). > > "Just" - if you can find the file in the source tree that is > > /Joe In your initial comment, you said "If I see a typo", not "if my wife sees a typo" :-) I suppose your wife isn't very used to downloading the 240 MBytes, unpacking them, fixing the file and publishing the change, either. This was the scenario for which I suggested a simpler alternative. There is an even better way, actually, even if it still requires a Github account in its current form. I don't remember where I saw it first, but I use it for the erlide documentation (which I am well aware that is lacking in all other respects): each generated page has at the bottom the message shown below, where the link opens the source file (markdown, in this case) from which it was generated in the on-line Github editor. This is something that could be added to the OTP docs too (but hand-editing Docbook XML is not as much fun as it sounds like :-\ ) > Did you find errors in the documentation? Do you have improvements to suggest? Suggest edits! best regards, Vlad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Fri Sep 23 16:31:27 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Fri, 23 Sep 2016 10:31:27 -0400 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <9C522EF0-478B-4CCB-9C5B-323574C7BBA1@writersglen.com> > My tentative currently looks similar to this for "man cowboy:start_clear": > https://gist.github.com/essen/3affa1c8e7805a7dc867156b03c1854f - in HTML/PDF >form it would of course have syntax highlighting, proper links and so on. Bravo! I believe I would be six months further along with my current project if Erlang docs followed this format. Yes, it would be an overwhelming task to bring current docs up to this standard. But--- A number of years ago a professional writer was under contract to write a book about birds. She was utterly overwhelmed by scope of the task. When she complained to a friend, her friend advised, "One bird at a time." Best to all, Lloyd Sent from my iPad > On Sep 23, 2016, at 5:17 AM, Lo?c Hoguin wrote: > > FYI I am currently working on improving the Cowboy function reference. My tentative currently looks similar to this for "man cowboy:start_clear": https://gist.github.com/essen/3affa1c8e7805a7dc867156b03c1854f - in HTML/PDF form it would of course have syntax highlighting, proper links and so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Fri Sep 23 17:35:17 2016 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Fri, 23 Sep 2016 17:35:17 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: I have followed this thread with interest there has been many good suggestions and comments and I will in a separate mail comment the OTP teams thinking about this. But first I must put some comment on Joes mail. On Fri, Sep 23, 2016 at 10:13 AM, Joe Armstrong wrote: > I have a few comments about the documentation: > > This answers a few question that keep arising, and has a few of my own > suggestions. > > Q: Who was the documentation written for? > > A: Ericsson Internal usage > > The original documentation made the following assumptions > > - The readers would be internal Ericsson programmers who knew Erlang > - If the programmers had a problem understanding things they would ask > us directly > > So we favored a terse declarative style > Since I joined the project (in 1996) I think the documentation is meant to be a reference manual which means it is not written for total beginners in programming. You are actually supposed to know something about Erlang and or functional programming when you read. > > Q: How is the documentation structured > A: It's all in XML > > The idea was that all documentation would be generated from the XML > There are current about 1000 XML files containing about 10MB of text > > The XML sources are in the distribution source tree. > So for example the documentation for lists.erl is in the file > /lib/stdlib/doc/src/lists.xml ( is where the system was > unpacked) > The idea is that the documentation is part of the SW delivery, it is in the same source code tree. Now it is in the same repository organized per OTP application. The principle is also that there is only one source of documentation which can be presented in many ways (generated by tools). The documentation should be written without thinking about layout and presentation. That part should be handled by the tools generating the different views. > > Q: How is the documentation produced > A: Programmatically > There is an otp application erl_docgen which is used for this. It takes the XML input and translates through several steps into unix man pages, html and pdf. > > Various programs munge the XML inputs (and the sources) trying to make > web-sites and PDF > > We could use some help here - really - the PDF is produced with > some XSLT magic > and the web site with goodness knows what. > The xml is translated to html by means of some preporcessing in Erlang and then an xslt transform executed with xsltproc which is pretty standard on any Linux system. The html is bundled together with a .css and a javascript for the left side navigation. Everything is passive, no active server is needed. It is "easy" to generate something nicer here without any impact on the doc sources. More about this in a separate mail. > > So what's wrong and what could we do? > > 1) Things are not beautiful > > I agree - the documentation is not typographically beautiful > > Personally I like PDF - I took a look and found this: > > http://www.latextemplates.com/template/the-legrand-orange-book > > It would be nice to transform the documentation into this form > for printing and reading > I am actually thinking that we don't need PDF at all. HTML should be enough. Man pages can also be questioned since they are limiting when it comes to format. Would be interesting to know how much use there is of our man pages?. > > 2) The HTML documentation could be improved and made more interactive > > I have at various times written 'erl_to_html' that makes HTML pages out > of > erlang - it would be nice to browse your own code, clicking on function > names > to follow the code or to unfold the documentation. > The html can be much improved. We are not experts on html and javascript, so help her is welcome. I have looked at the Elixir documentation generated with their ex_doc. The same or similar layout would be easy and suitable to use for Erlang as well and the communities are overlapping anyway so it would perhaps be a good idea to have a similar layout. I think it looks quite pretty. > > On-line documentation can have things like type spec in hidden folds > which open in place when you click on them. Or possibly a tiddly-wiki > like > interface. > > http://tiddlywiki.com/ might inspire a new interface > > 3) There is no official proof-reading quality control mechanism > > I tried on several occasions to hire a technical author - management > always > views this as a waste of money - so this never happened. > We have technical writers engaged since some years now. But they can only look after the language and the consistency of naming things etc. They can not add new text or examples. > > Most of the documentation is written by people who are not > native English speakers. They could use some help. > > By contract my Erlang book had > > - Me (who wrote it) > - Dave Thomas (my editor) (he was great) > - A Proof Reader (By proof reader I mead one of these super-human > beings > who can spot a spelling error at 10,000 meters from your text, > while reading upside down by candle light > - An Indexer (did you know there were professional Indexers?) > - A typographer (who worried about > https://en.wikipedia.org/wiki/Widows_and_orphans) > > Have you every heard *anybody* complaining about widows and orphans > in the Erlang printed documentation? I had to rephrase several > paragraphs to avoid nasty widows and orphans. > > 4) There are no examples > > I agree there should be zillions of examples. > > Rather than adding them to the existing XML tree I'd propose a new > DTD for examples which could be cross-linked into the > documentation. > I agree that there should be more examples and I think they should be placed in the existing xml-files or in a separate file per module, but still treated as documentation source. Then there can be several alternatives for how they are presented, but this is a tooling or html output question. > > > 5) There are no construction examples > > Examples show "the finished work" but not "how you got there" > > In my book I often shown really short functions in 10 lines or so > of code. But I don't discuss how I got to those ten lines. > > I show the 10 lines and explain what each lines does. > > I do not explain how I wrote the first line - I might have googled > a bit done some research. In a 50 line program I'll probably have > tested it as I grew it - testing 10 lines at a time. > > How we grow programs from small seeds is not explained. > This does not belong to the reference manual. But somewhere else, I don't know where. > > 6) The barrier for entry for fixing a typo is HUGE > > If I see a typo (a simple spelling error) in the on-line documentation > the barrier of entry for fixing it is HUGE (sorry for SHOUTING). > > Download the entire distribution - unpack (240 MBytes) find the > typo (where the heck is it?) - fix it - make a push request .... > > Do I really have to download hundreds of Megabytes to fix a one > character typo? > I agree that it should be simple to correct a simple typo, and it seems to be a way through github , we will explore that and describe it. I link to the doc source at github could for example be generated into the html representation of a module. Then it would be obvious in which file to fix the error. > > I keep pointing people to the web site for "real world Haskell" > http://book.realworldhaskell.org/read/functional-programming.html > > The barrier for entry to fixing a mistake in the text is minimal. > I actually like the RWH model - the reader adds a comment, the author > fixes > the bug. > > When writing books I would not like other people fixing my typos, I > want many eyes to help be find the typos - then I'll fix them? Why > is this? Because I'm ultimately responsible for what I write - > Sometimes (not often) I might want to totally rewrite a section > based on a single typo. > > If somebody could figure out how to automate fixing typos it would be > great. > [the problem is to find the XML that needs to be edited, given that the > error > was found in a generated document - I guess if each paragraph has > a hidden GUID > <> it would be trivial] > > > > > 7) The erlang mailing list has loads of examples > > The erlang mailing list has thousands of useful examples > but they are not extracted, edited sorted and classified. > > There are issues of copyright and attribution here - but I think > it would be useful to extract some of the better postings to this list > and move them into the documentation tree. > > > Making beautiful readable useful documentation is very difficult and > needs love care and attention to detail - it's an unappreciated form > of literature. > /Kenneth, Erlang/OTP Ericsson > > On Fri, Sep 23, 2016 at 8:40 AM, Lo?c Hoguin wrote: > > On 09/23/2016 05:18 AM, Kenneth Lakin wrote: > >> > >> Speaking of the User's Guide... -ideally- someone with no Erlang > >> experience should first be reading the Reference Manual User's Guide > >> along with the Getting Started Guide (or LYSE or something) to pick up > >> the fundamentals, rather than the various module Reference Manuals. In > >> my experience, reference manuals exist to quickly provide useful > >> information to people who are already familiar with a language. They > >> shouldn't be language primers, as primers serve another purpose and > >> should be in another document. > > > > > > That's the thing: you have no control over what document people will read > > first. You also have no control over what people will *remember*. > > > > When first coming to the language, most people will > > forget/misremember/misunderstand most of what they read until they get > some > > practice; and that's when a good function reference with all details and > > examples is helpful. > > > > > > -- > > Lo?c Hoguin > > http://ninenines.eu > > Author of The Erlanger Playbook, > > A book about software development using Erlang > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Sep 23 17:50:59 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 23 Sep 2016 17:50:59 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <2e934523-8380-d515-8401-adedd60f50ea@ninenines.eu> On 09/23/2016 05:35 PM, Kenneth Lundin wrote: > So what's wrong and what could we do? > > 1) Things are not beautiful > > I agree - the documentation is not typographically beautiful > > Personally I like PDF - I took a look and found this: > > http://www.latextemplates.com/template/the-legrand-orange-book > > > It would be nice to transform the documentation into this form > for printing and reading > > > I am actually thinking that we don't need PDF at all. HTML should be enough. > Man pages can also be questioned since they are limiting when it comes > to format. > Would be interesting to know how much use there is of our man pages?. I use the man pages almost on a daily basis, so much that I added them to MANPATH and can just "man erlang" and such. I rely on them even more when I have little or no connection to Internet. I go online mostly for the user guides and for searching using erldoc when I can't remember names. Of note, Cowboy and Ranch have had man pages for a few years now, and are typically my go-to when I forget something. The inspiration for making those available as man pages actually comes from Erlang's man pages. I do not know how many people use those though, probably not a lot. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From erlang.org@REDACTED Fri Sep 23 18:19:51 2016 From: erlang.org@REDACTED (Stanislaw Klekot) Date: Fri, 23 Sep 2016 18:19:51 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <2e934523-8380-d515-8401-adedd60f50ea@ninenines.eu> References: <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <2e934523-8380-d515-8401-adedd60f50ea@ninenines.eu> Message-ID: <20160923161951.GA2122@jarowit.net> On Fri, Sep 23, 2016 at 05:50:59PM +0200, Lo?c Hoguin wrote: [...] > >I am actually thinking that we don't need PDF at all. HTML should be enough. > >Man pages can also be questioned since they are limiting when it comes > >to format. > >Would be interesting to know how much use there is of our man pages?. > > I use the man pages almost on a daily basis, so much that I added > them to MANPATH and can just "man erlang" and such. I rely on them > even more when I have little or no connection to Internet. I go > online mostly for the user guides and for searching using erldoc > when I can't remember names. > > Of note, Cowboy and Ranch have had man pages for a few years now, > and are typically my go-to when I forget something. The inspiration > for making those available as man pages actually comes from Erlang's > man pages. I do not know how many people use those though, probably > not a lot. I use man pages (and similar things, like info, perldoc, or pydoc) a lot. Every time I use my own library, which has documentation autogenerated with EDoc, I regret that I haven't put some more effort to prepare a man page, compared to what Erlang distribution provides. -- Stanislaw Klekot From devangana@REDACTED Fri Sep 23 18:47:27 2016 From: devangana@REDACTED (Devangana Tarafdar) Date: Fri, 23 Sep 2016 11:47:27 -0500 Subject: [erlang-questions] SNMP v3 usmStatsNotInTimeWindows error In-Reply-To: References: <5d9ce09e-3721-9d61-619e-76ebc2e58970@yahoo.co.uk> Message-ID: Hi, Thanks so much ! It worked. I applied the patch to 17.1 as well as 19, since the file snmpm_usm.erl had not changed, (would you recommend doing that, applying it to 19 when it was written for 17.1 ? ) and they both worked. Also thanks for your patience, I realize that I have not been too prompt in replying to your suggestions, (getting pulled into other projects and can only come back to this for some hours in a week :-( ). Best, Devangana On Mon, Sep 19, 2016 at 8:46 AM, Devangana Tarafdar wrote: > Sorry about the late reply Daniel, I missed the email. > > Yes the engine id was correct in the wireshark trace. That was the first > thing I had to correct. I had to convert the engine id string to an > explicit list of decimals for the id. > > On Sep 15, 2016 10:52 AM, "Daniel Goertzen" > wrote: > >> Check that the engine ids are what you expect them to be. You've >> redacted all the engine ids from the trace, so I can't check them. >> >> The SNMP config files have trouble storing non-ascii engine ids; not sure >> if this affect you. This should be fixed agent-side for 19.1, not sure >> about manager-side. >> >> On Wed, Sep 14, 2016 at 1:42 PM Devangana Tarafdar >> wrote: >> >>> Hi Dominik, >>> >>> So I was able look at the wireshark stream decoded after entering snmp >>> credentials (that was very helpful, thanks !) and compared the 2 streams : >>> One from the snmp get tool and the other from the erlang script. >>> >>> Wireshark is not able to decode the encrypted pdu in the erlang stream >>> but it can decode the snmpget stream. >>> >>> The message is clear enough I suppose but I don't know what I am doing >>> wrong with the key. >>> >>> I changed my local key generation to : >>> >>> %Priv_key_local = snmp:passwd2localized_key(sha, Priv_key , >>> Agent_engine_id), >>> >>> % since auth protocol is SHA >>> Priv_key_local = lists:sublist(snmp:passwd2localized_key(sha, >>> Priv_key , Agent_engine_id),16), >>> >>> but it did not help. >>> >>> >>> msgData: encryptedPDU (1) >>> encryptedPDU: 8a3e7fc633c531d2747782a6fc8d89 >>> 187c452929426e4b6e... >>> Decrypted data not formatted as expected, wrong key? >>> [Expert Info (Warn/Malformed): Decrypted data not >>> formatted as expected] >>> [Message: Decrypted data not formatted as expected] >>> [Severity level: Warn] >>> [Group: Malformed] >>> >>> >>> Attaching good wireshark trace from snmpget and a bad one from erlang. >>> >>> Also tried putting a context name but did not work but snmpget does not >>> put one and it works. >>> >>> Thanks, >>> Devangana >>> >>> >>> >>> On Sun, Sep 11, 2016 at 4:09 PM, Devangana Tarafdar >> > wrote: >>> >>>> Hi Dominik, >>>> >>>> I have not looked into the context. Will check all the items that you >>>> mention. I have been able to connect to the agent using snmpwalk and >>>> snmpget though I have not studied the wireshark output of those in detail. >>>> Thanks again for all these tips and I will get back to you . >>>> >>>> Devangana >>>> >>>> On Sep 11, 2016 3:08 PM, "Dominik Pawlak" >>>> wrote: >>>> >>>>> Hello Devangana, >>>>> Hard to tell, but I see that you haven't specified any context in your >>>>> sync_get. Are you sure it is not needed? I would also double check the >>>>> engine id and security configuration. >>>>> Have you managed to connect to that agent from something other than >>>>> OTP (say snmpb, snmpget)? >>>>> If so, you can compare in Wireshark, the snmp requests from erlang and >>>>> from that tool. You can even enter your snmp credentials in Wireshark and >>>>> it will decode encrypted messages. >>>>> I hope any of this helps. >>>>> >>>>> Best >>>>> Dominik >>>>> >>>>> On 11.09.2016 16:46, Devangana Tarafdar wrote: >>>>> >>>>> Hello Dominik, >>>>> >>>>> Thanks you for the reply. >>>>> >>>>> I sent another sync_get after the first as you suggested. The >>>>> wireshark trace shows the manager has updated the >>>>> 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' to the >>>>> values sent by the Agent as you pointed out. But now the agent does not >>>>> respond at all and the sync_get fails with a timeout. I tried adding a >>>>> second's sleep between the 2 gets as well. I don't have access currently to >>>>> the agent's logs or configuration but have you seen this before ? >>>>> >>>>> Thanks ! >>>>> Devangana >>>>> >>>>> >>>>> On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak < >>>>> dominik_pawlak@REDACTED> wrote: >>>>> >>>>>> Hello Devangana, >>>>>> Basically, you just have to perform the sync_get once more. I >>>>>> observed similar behavior in OTP 17.1 (snmp 4.25.1). The first request will >>>>>> always fail because the manager is not fully configured to communicate with >>>>>> the agent (more on that below). >>>>>> >>>>>> A longer explanation: >>>>>> >>>>>> In snmp v3 there is a process called 'discovery', which should be >>>>>> performed before secure communication with the agent can be established. It >>>>>> is described here: >>>>>> >>>>>> https://tools.ietf.org/html/rfc3414#section-4 >>>>>> >>>>>> The snmp library in OTP does not implement that process (at least not >>>>>> as described in the RFC). >>>>>> This process has two steps: 'snmpEngineID discovery' and 'time >>>>>> synchronization'. >>>>>> The first step is skipped altogether in OTP - you have to provide >>>>>> engine id upfront. >>>>>> The second step is performed by the first request - it will always >>>>>> fail with the 'usmStatsNotInTimeWindows' error report message, but it will >>>>>> set the required 'msgAuthoritativeEngineBoots' and >>>>>> 'msgAuthoritativeEngineTime' in the manager. >>>>>> >>>>>> Best, >>>>>> Dominik >>>>>> >>>>>> >>>>>> On 10.09.2016 06:48, Devangana Tarafdar wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am trying to connect to a third party SNMP agent, using snmp >>>>>> manager (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running >>>>>> into a problem where the agent is returning this error on the manager >>>>>> calling sync_get: >>>>>> >>>>>> >>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>>>> handle_snmp_report -> entry with >>>>>> Domain: snmpUDPDomain >>>>>> Addr: {{xx,xxx,xxx,xxx},161} >>>>>> ReqId: 37078226 >>>>>> Rep: {invalid_sec_info,[{sec_level,3,1}, >>>>>> {request_id,37078226,2147483647}]} >>>>>> Pdu: {pdu,report,2147483647,noError,0, >>>>>> [{varbind,[1,3,6,1,6,3,15,1,1 >>>>>> ,2,0],'Counter32',33,1}]} >>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG *** >>>>>> handle_snmp_report -> found corresponding request: >>>>>> reply to sync request >>>>>> Ref: #Ref<0.0.4.210> >>>>>> ModRef: #Ref<0.0.4.211> >>>>>> From: {<0.3.0>,#Ref<0.0.4.202>} >>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>>>> handle_snmp_pdu(get-response) -> Remaining: 4979 >>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE *** >>>>>> handle_snmp_report -> deliver reply >>>>>> >>>>>> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226, >>>>>> 2147483647}],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2, >>>>>> 0],'Counter32',33,1}]}}} >>>>>> >>>>>> *** [2016:09:08 21:26:00 831] >>>>>> >>>>>> Where [1,3,6,1,6,3,15,1,1,2,0] maps to "usmStatsNotInTimeWindows" >>>>>> (from http://www.oid-info.com/) >>>>>> >>>>>> I have attached a wireshark trace for the snmp part of this exchange. >>>>>> >>>>>> I am invoking the snmpm module functions through a basic script as >>>>>> follows (using tips from the tutorial at >>>>>> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start ) >>>>>> ......... >>>>>> .......... >>>>>> >>>>>> ok = application:start(crypto), >>>>>> ok = application:start(snmp), >>>>>> >>>>>> Userid = "snmp3user", >>>>>> Agent_target = "testagent", >>>>>> Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176], >>>>>> Agent_ip = {xx,xxx,xxx,xxx}, >>>>>> Agent_port = 161 , >>>>>> Secure_name= Userid, >>>>>> >>>>>> Security_level = 'authPriv', >>>>>> Security_model = 'usm', >>>>>> Agent_version = 'v3', >>>>>> Auth_protocol = 'usmHMACSHAAuthProtocol', >>>>>> Priv_protocol = 'usmAesCfb128Protocol', >>>>>> >>>>>> % this is 16 in length >>>>>> Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id), >>>>>> >>>>>> % this is 20 in length >>>>>> Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id), >>>>>> >>>>>> ok = snmpm:register_user(Userid,snmpm_user_default,[]), >>>>>> >>>>>> ok = snmpm:register_usm_user(Agent_engine_id, Userid, [ >>>>>> {auth, Auth_protocol}, >>>>>> {auth_key,Auth_key_local}, >>>>>> {priv, Priv_protocol}, >>>>>> {priv_key,Priv_key_local }, >>>>>> {sec_name, Secure_name} >>>>>> ]), >>>>>> ok = snmpm:register_agent(Userid, Agent_target ,[ >>>>>> {engine_id,Agent_engine_id}, >>>>>> {address, Agent_ip}, >>>>>> {port, Agent_port}, >>>>>> {version,Agent_version}, >>>>>> {sec_model,Security_model}, >>>>>> {sec_name,Secure_name}, >>>>>> {sec_level, Security_level} >>>>>> >>>>>> ]), >>>>>> Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]), ........................ >>>>>> >>>>>> ........................ >>>>>> >>>>>> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated ! >>>>>> >>>>>> Thanks, Devangana >>>>>> >>>>>> _______________________________________________ >>>>>> 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 carlsson.richard@REDACTED Fri Sep 23 23:51:01 2016 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 23 Sep 2016 23:51:01 +0200 Subject: [erlang-questions] [ANN] Mnesia eleveldb backend 1.0 Message-ID: Finally, as promised: all you need in order to use Mnesia to manage unhealthy amounts of data: https://github.com/klarna/mnesia_eleveldb Apache 2.0 license. Requires Erlang/OTP 19 or later, or an earlier version with the mnesia_ext patch added (see http://erlang.org/pipermail/erlang-questions/2015-July/085046.html). Most of the actual work has been done by Ulf Wiger and Mikael Pettersson. eleveldb itself is the work of Basho; we take no credit for that. Documentation is rudimentary; OTP 19 doesn't seem to include the actual docs for the mnesia_ext patch yet. On the other hand, you don't need to know much about how the plugin interface works in order to use this backend - you simply get a new table type. See the REAME for some caveats. You may also want to use this add-on to make backups easier: https://github.com/klarna/leveldb_manager (we're not sure if it's needed with the more recent versions of leveldb). /Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nayibor@REDACTED Sat Sep 24 02:29:14 2016 From: nayibor@REDACTED (Nuku Ameyibor) Date: Sat, 24 Sep 2016 00:29:14 +0000 Subject: [erlang-questions] Packing and unpacking iso8583 messages Message-ID: Dear List , I am writing a program where i need to pack/unpack iso messages . i am using the erl8583 application but i am getting some errors using the packing and unpacking functions of the library . i run the test_all.erl test script which runs the eunit scripts but got some errors . i scaled it down and run the test_asci_marshaller.erl eunit test . below is part of the output below eunit:test(test_ascii_marshaller). > test_ascii_marshaller: pan_test...*failed* > in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) > called as marshal_data_element({n,fixed,4},<<"0200">>) > in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) > in call from test_ascii_marshaller:pan_test/0 (test/test_ascii_marshaller.erl, line 43) > **error:function_clause > output:<<"">> > > test_ascii_marshaller: proc_code_test...*failed* > in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) > called as marshal_data_element({n,fixed,4},<<"0100">>) > in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) > in call from test_ascii_marshaller:proc_code_test/0 (test/test_ascii_marshaller.erl, line 49) > **error:function_clause > output:<<"">> > > test_ascii_marshaller: amount_tran_test...*failed* > in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) > called as marshal_data_element({n,fixed,4},<<"0200">>) > in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) > in call from test_ascii_marshaller:amount_tran_test/0 (test/test_ascii_marshaller.erl, line 55) > **error:function_clause > output:<<"">> > > i traced it down to this line in this line in erl8583_marshaller_ascii.erl > marshal_data_element({n, fixed, Length}, FieldValue) when length(FieldValue) =< Length -> > IntValue = list_to_integer(FieldValue), > erl8583_convert:integer_to_string(IntValue, Length); > > i may be wrong but seems the length(FieldValue) is being passed a binary string instead of as string ?? running some of the functions in the application eg . below Msg1 = erl8583_message:new(), > Msg2 = erl8583_message:set(0, "0200", Msg1), > Msg3 = erl8583_message:set(2, "5234567890123456", Msg1), > AsciiMessage =erl8583_marshaller_ascii:marshal(Msg3), > gives the below error a similar example is included in the test cases and i am assuming its supposed to work . terminate reason: {undef, > [{undefined,get_encoding,[2],[]}, > {erl8583_marshaller_ascii,marshal_field,3, > [{file,"src/erl8583_marshaller_ascii.erl"}, > {line,109}]}, > {erl8583_marshaller,encode,6, > [{file,"src/erl8583_ > marshaller.erl"},{line,238}]}, > {erl8583_marshaller,marshal,2, > [{file,"src/erl8583_ > marshaller.erl"},{line,112}]}, > Anyone have any experience with using this library and can help point out what i may be doing wrong . Also are there any other libraries out there for packing and unpacking iso 8583 messages in erlang . searched on github but dont seem to find anything except erl8583 and some forks of it . Are there other alternative approaches for this like the use of ports to help with the packing/unpacking ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgisinger@REDACTED Sat Sep 24 03:24:21 2016 From: hgisinger@REDACTED (Hernando Gisinger) Date: Fri, 23 Sep 2016 22:24:21 -0300 Subject: [erlang-questions] Packing and unpacking iso8583 messages In-Reply-To: References: Message-ID: Maybe ? Msg1 = erl8583_message:new(), Msg2 = erl8583_message:set(0, "0200", Msg1), Msg3 = erl8583_message:set(2, "5234567890123456", Msg2), %% Here is Msg2, not Msg1 AsciiMessage =erl8583_marshaller_ascii:marshal(Msg3), 2016-09-23 21:29 GMT-03:00 Nuku Ameyibor : > Dear List , > > I am writing a program where i need to pack/unpack iso messages . > i am using the erl8583 application > but i am getting some errors using the packing and unpacking functions of > the library . > i run the test_all.erl > > test script which runs the eunit scripts but got some errors . > i scaled it down and run the test_asci_marshaller.erl eunit test . > below is part of the output below > > eunit:test(test_ascii_marshaller). >> test_ascii_marshaller: pan_test...*failed* >> in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) >> called as marshal_data_element({n,fixed,4},<<"0200">>) >> in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) >> in call from test_ascii_marshaller:pan_test/0 (test/test_ascii_marshaller.erl, line 43) >> **error:function_clause >> output:<<"">> >> >> test_ascii_marshaller: proc_code_test...*failed* >> in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) >> called as marshal_data_element({n,fixed,4},<<"0100">>) >> in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) >> in call from test_ascii_marshaller:proc_code_test/0 (test/test_ascii_marshaller.erl, line 49) >> **error:function_clause >> output:<<"">> >> >> test_ascii_marshaller: amount_tran_test...*failed* >> in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) >> called as marshal_data_element({n,fixed,4},<<"0200">>) >> in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) >> in call from test_ascii_marshaller:amount_tran_test/0 (test/test_ascii_marshaller.erl, line 55) >> **error:function_clause >> output:<<"">> >> >> > i traced it down to this line in this line in erl8583_marshaller_ascii.erl > >> marshal_data_element({n, fixed, Length}, FieldValue) when length(FieldValue) =< Length -> >> IntValue = list_to_integer(FieldValue), >> erl8583_convert:integer_to_string(IntValue, Length); >> >> > i may be wrong but seems the length(FieldValue) is being passed a binary > string instead of as string ?? > running some of the functions in the application eg . below > > Msg1 = erl8583_message:new(), >> Msg2 = erl8583_message:set(0, "0200", Msg1), >> Msg3 = erl8583_message:set(2, "5234567890123456", Msg1), >> AsciiMessage =erl8583_marshaller_ascii:marshal(Msg3), >> > > gives the below error > a similar example is included in the test cases and i am assuming its > supposed to work . > > terminate reason: {undef, >> [{undefined,get_encoding,[2],[]}, >> {erl8583_marshaller_ascii,marshal_field,3, >> [{file,"src/erl8583_marshaller_ascii.erl"}, >> {line,109}]}, >> {erl8583_marshaller,encode,6, >> [{file,"src/erl8583_marshaller >> .erl"},{line,238}]}, >> {erl8583_marshaller,marshal,2, >> [{file,"src/erl8583_marshaller >> .erl"},{line,112}]}, >> > > > > > Anyone have any experience with using this library and can help point out > what i may be doing wrong . > Also are there any other libraries out there for packing and unpacking iso > 8583 messages in erlang . > searched on github but dont seem to find anything except erl8583 and some > forks of it . > Are there other alternative approaches for this like the use of ports to > help with the packing/unpacking ? > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nayibor@REDACTED Sat Sep 24 03:35:10 2016 From: nayibor@REDACTED (Nuku Ameyibor) Date: Sat, 24 Sep 2016 01:35:10 +0000 Subject: [erlang-questions] Fwd: Packing and unpacking iso8583 messages In-Reply-To: References: Message-ID: tried it but does not seem to make a difference . % Create a message. > Msg1 = erl8583_message:new(), > Msg2 = erl8583_message:set(0, "0200", Msg1), > Msg3 = erl8583_message:set(2, "5234567890123456", Msg2), > AsciiMessage =erl8583_marshaller_ascii:marshal(Msg3), > error message below terminate reason: {function_clause, [{erl8583_marshaller_ascii,marshal_data_element, [{n,fixed,4},<<"0200">>], [{file,"src/erl8583_marshaller_ascii.erl"}, {line,168}]}, {erl8583_marshaller,marshal,2, [{file,"src/erl8583_marshaller.erl"},{line,108}]}, On Sat, Sep 24, 2016 at 1:24 AM, Hernando Gisinger wrote: > Maybe ? > > Msg1 = erl8583_message:new(), > Msg2 = erl8583_message:set(0, "0200", Msg1), > Msg3 = erl8583_message:set(2, "5234567890123456", Msg2), %% Here is Msg2, > not Msg1 > AsciiMessage =erl8583_marshaller_ascii:marshal(Msg3), > > 2016-09-23 21:29 GMT-03:00 Nuku Ameyibor : > >> Dear List , >> >> I am writing a program where i need to pack/unpack iso messages . >> i am using the erl8583 >> application but i am getting some errors using the packing and unpacking >> functions of the library . >> i run the test_all.erl >> >> test script which runs the eunit scripts but got some errors . >> i scaled it down and run the test_asci_marshaller.erl eunit test . >> below is part of the output below >> >> eunit:test(test_ascii_marshaller). >>> test_ascii_marshaller: pan_test...*failed* >>> in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) >>> called as marshal_data_element({n,fixed,4},<<"0200">>) >>> in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) >>> in call from test_ascii_marshaller:pan_test/0 (test/test_ascii_marshaller.erl, line 43) >>> **error:function_clause >>> output:<<"">> >>> >>> test_ascii_marshaller: proc_code_test...*failed* >>> in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) >>> called as marshal_data_element({n,fixed,4},<<"0100">>) >>> in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) >>> in call from test_ascii_marshaller:proc_code_test/0 (test/test_ascii_marshaller.erl, line 49) >>> **error:function_clause >>> output:<<"">> >>> >>> test_ascii_marshaller: amount_tran_test...*failed* >>> in function erl8583_marshaller_ascii:marshal_data_element/2 (src/erl8583_marshaller_ascii.erl, line 168) >>> called as marshal_data_element({n,fixed,4},<<"0200">>) >>> in call from erl8583_marshaller:marshal/2 (src/erl8583_marshaller.erl, line 108) >>> in call from test_ascii_marshaller:amount_tran_test/0 (test/test_ascii_marshaller.erl, line 55) >>> **error:function_clause >>> output:<<"">> >>> >>> >> i traced it down to this line in this line in erl8583_marshaller_ascii.erl >> >>> marshal_data_element({n, fixed, Length}, FieldValue) when length(FieldValue) =< Length -> >>> IntValue = list_to_integer(FieldValue), >>> erl8583_convert:integer_to_string(IntValue, Length); >>> >>> >> i may be wrong but seems the length(FieldValue) is being passed a binary >> string instead of as string ?? >> running some of the functions in the application eg . below >> >> Msg1 = erl8583_message:new(), >>> Msg2 = erl8583_message:set(0, "0200", Msg1), >>> Msg3 = erl8583_message:set(2, "5234567890123456", Msg1), >>> AsciiMessage =erl8583_marshaller_ascii:marshal(Msg3), >>> >> >> gives the below error >> a similar example is included in the test cases and i am assuming its >> supposed to work . >> >> terminate reason: {undef, >>> [{undefined,get_encoding,[2],[]}, >>> {erl8583_marshaller_ascii,marshal_field,3, >>> [{file,"src/erl8583_marshaller_ascii.erl"}, >>> {line,109}]}, >>> {erl8583_marshaller,encode,6, >>> [{file,"src/erl8583_marshaller >>> .erl"},{line,238}]}, >>> {erl8583_marshaller,marshal,2, >>> [{file,"src/erl8583_marshaller >>> .erl"},{line,112}]}, >>> >> >> >> >> >> Anyone have any experience with using this library and can help point >> out what i may be doing wrong . >> Also are there any other libraries out there for packing and unpacking >> iso 8583 messages in erlang . >> searched on github but dont seem to find anything except erl8583 and some >> forks of it . >> Are there other alternative approaches for this like the use of ports to >> help with the packing/unpacking ? >> >> >> >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding@REDACTED Sat Sep 24 19:50:12 2016 From: rvirding@REDACTED (Robert Virding) Date: Sat, 24 Sep 2016 19:50:12 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On 23 September 2016 at 11:17, Lo?c Hoguin wrote: > On 09/23/2016 10:36 AM, Lutz Behnke wrote: > >> I would propose a position specific to the reference documentation: >> >> 8) Put the documentation in the source code. Use edoc (or similar new >> tool). >> > > And I would strongly advise against that. > > I definitely agree with Lo?c here but from the programmers viewpoint. When working with the code I need (good) documentation which describes what the code is doing from the internal POV. I definitely DON'T need documentation for the user on how to use and what it means and examples and ... . That just clutters up the page for me writing/maintaining the code. Note that I am NOT saying the user doesn't need all that, the user definitely does need/require all that, but it should be somewhere else not mixed in with the code. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From bildeyko@REDACTED Sat Sep 24 19:43:30 2016 From: bildeyko@REDACTED (Nikolay Bildeyko) Date: Sat, 24 Sep 2016 20:43:30 +0300 Subject: [erlang-questions] Error: Node is not running Message-ID: <1608ec62-4828-7ddd-6df9-7af4175ce5bb@gmail.com> Dear List, I have a problem with attachment to my running application. On my Amazon server (Amazon Linux) it works great, but on my local machine (Linux Mint 17.3) I have next problem: I start application with name ServerDev@REDACTED: bin/server start when I want to attach I have an error: bin/server attach Node is not running! Although epmd say me that app is running and I can get data from app by curl: epmd -names epmd: up and running on port 4369 with data: name ServerDev at port 47963 Log files are empty. Also I can't stop the app. stop command does nothing. install command also doesn't work. About versions: rebar 3.2.0 and Erlang/OTP 19 Erts 8.0 Cheers, Nikolay Bildeyko -------------- next part -------------- An HTML attachment was scrubbed... URL: From list1@REDACTED Sun Sep 25 11:06:49 2016 From: list1@REDACTED (Grzegorz Junka) Date: Sun, 25 Sep 2016 09:06:49 +0000 Subject: [erlang-questions] Error: Node is not running In-Reply-To: <1608ec62-4828-7ddd-6df9-7af4175ce5bb@gmail.com> References: <1608ec62-4828-7ddd-6df9-7af4175ce5bb@gmail.com> Message-ID: <93928b91-233a-848d-b31c-a54495acd59d@gjunka.com> On 24/09/2016 17:43, Nikolay Bildeyko wrote: > Dear List, > > I have a problem with attachment to my running application. On my > Amazon server (Amazon Linux) it works great, but on my local machine > (Linux Mint 17.3) I have next problem: > I start application with name ServerDev@REDACTED: > bin/server start > when I want to attach I have an error: > bin/server attach > Node is not running! > > Although epmd say me that app is running and I can get data from app > by curl: > epmd -names > epmd: up and running on port 4369 with data: > name ServerDev at port 47963 > > Log files are empty. > Also I can't stop the app. stop command does nothing. install command > also doesn't work. > > About versions: > rebar 3.2.0 and Erlang/OTP 19 Erts 8.0 > > Cheers, > Nikolay Bildeyko That usually happens when you start the node with -name (indicating a long name) where the name isn't a valid FQDN (isn't properly resolved by DNS). How do you supply the name of the node, with -name or -sname? If the former, can you resolve that name to IP with dig or drill? Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From kunthar@REDACTED Sun Sep 25 21:00:51 2016 From: kunthar@REDACTED (Gokhan Boranalp) Date: Sun, 25 Sep 2016 22:00:51 +0300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: Greetings, There should be some predefined categories of doc types; 1. Code 1.a. Clear listings of methods/classes with proper links to jump whenever needed. check Java API[1]. 1.b. Comments and basic usage examples for every single function within code. 1.c. Editor IDE helpers/plugins to show usage, autocomplete/jump from one module/function to another. 1.d Proper error definitions to find wtf is wrong preferably connect them to stackoverflow or http://lmgtfy.com/ to ask others. 1.e Pure proper error definitions to correctly trace, which module screwed before this module spits bunch of tuples out to the console. 2. General help articles to explain more specific topic. Something like gen_server explanation[2] etc. 3. Tutorial style, story based help starts with first step and follows to last step to show coder how to do things. 4. Advocate articles. Someone writes how your language/toolset is "Det b?sta"[3] in several blogs. 5. Of course books. As it can be seen clearly, they have a different purpose and there is no orthogonal way to adjust all of them to the one place. Most of them already ready but problem is, they are not organized in this way to locate "easily". I strongly propose to make clear doc category tree and rethink about all documentation in all levels for "Det b?sta" Erlang. br [1] https://docs.oracle.com/javase/7/docs/api/ [2] http://erlang.org/doc/man/gen_server.html [3] https://translate.google.com/#sv/en/Det%20b%C3%A4sta On Sat, Sep 24, 2016 at 8:50 PM, Robert Virding wrote: > On 23 September 2016 at 11:17, Lo?c Hoguin wrote: >> >> On 09/23/2016 10:36 AM, Lutz Behnke wrote: >>> >>> I would propose a position specific to the reference documentation: >>> >>> 8) Put the documentation in the source code. Use edoc (or similar new >>> tool). >> >> >> And I would strongly advise against that. >> > > I definitely agree with Lo?c here but from the programmers viewpoint. When > working with the code I need (good) documentation which describes what the > code is doing from the internal POV. I definitely DON'T need documentation > for the user on how to use and what it means and examples and ... . That > just clutters up the page for me writing/maintaining the code. > > Note that I am NOT saying the user doesn't need all that, the user > definitely does need/require all that, but it should be somewhere else not > mixed in with the code. > > Robert > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- BR, \|/ Kunthar From vans_163@REDACTED Sun Sep 25 19:32:19 2016 From: vans_163@REDACTED (Vans S) Date: Sun, 25 Sep 2016 17:32:19 +0000 (UTC) Subject: [erlang-questions] gen_statem and multiple timeout vs 1 References: <917841123.4519860.1474824739386.ref@mail.yahoo.com> Message-ID: <917841123.4519860.1474824739386@mail.yahoo.com> Learning the new gen_statem made me desire for one extra feature. Say you have a common use case of a webserver /w websockets, you have a general connection timeout of 120s, if no messages are received in 120s it means the socket is in an unknown state, and should be closed. So you write your returns like this anytime the client sends you a message: {next_state, NextState, NewData, {timeout, 120*1000, idle_timeout}} Now if the client does not send any messages in 120 seconds, we will get a?idle_timeout?message sent to the gen_statem process. Awesome. But enter a little complexity, enter websockets. Now we need to send a ping from the gen_statem every 15s to the client, but we also need to consider if we did not get any messages from the client in 120s, we are in unknown state and should terminate the connection. So now we are just itching to do this on init: {ok, initial_state, Data, [? ? ? ? {timeout, 120*1000,?idle_timeout},? ? ? ? {timeout, 15*1000, websocket_ping} ????]} This way we do not need to manage our own timers using erlang:send_after. ?timer module is not even a consideration due to how inefficient it is at scaling. But of course we cannot do this, the latest timeout will always override any previous. What do you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: From skribent_har@REDACTED Sun Sep 25 21:38:39 2016 From: skribent_har@REDACTED (Martin Hedberg) Date: Sun, 25 Sep 2016 19:38:39 +0000 Subject: [erlang-questions] Blockchain and Erlang Message-ID: Hi everyone This is more of a theoretical question then a strictly practical one. However there is no more practical then a good theory ...right? Anyway I wonder if the blockchain method of keeping track of every node could be applied to a sort of Erlang-blockchain combination? If every Erlang node would be a blockchain-like supervisor would that make things unnecessary complicated or is there some potential stability to gain? Just a thought from me Best regards Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sun Sep 25 22:26:49 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 25 Sep 2016 22:26:49 +0200 Subject: [erlang-questions] Blockchain and Erlang In-Reply-To: References: Message-ID: On Sun, Sep 25, 2016 at 9:38 PM, Martin Hedberg wrote: > Anyway I wonder if the blockchain method of keeping track of every node > could be applied to a sort of Erlang-blockchain combination? If every > Erlang node would be a blockchain-like supervisor would that make things > unnecessary complicated or is there some potential stability to gain? What property do you want to gain from that? Blockchains are: * A chain of blocks. Usually where each block sign/content-address its predecessor * A proof of work algorithm for producing a new block The nice property is that the chain allows you to go back in time and ask about historical data, while providing integrity: the chain opposes historic rewrites as time passes. They have other nice properties as well, but I must admit I fail to see where those properties fit into the idea of supervision. For (loose) consensus it may work, but there are other algorithms which tend to fare better for this situation, because a typical Erlang cluster doesn't require the integrity properties of the blockchain. Note: I don't dismiss the idea, but I fail to see where it is applicable. Can you possibly elaborate? -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlml@REDACTED Sun Sep 25 22:02:06 2016 From: erlml@REDACTED (Elias Rohrer) Date: Sun, 25 Sep 2016 22:02:06 +0200 Subject: [erlang-questions] Blockchain and Erlang In-Reply-To: References: Message-ID: Hello Martin, On 25 Sep 2016, at 21:38, Martin Hedberg wrote: > Hi everyone > > This is more of a theoretical question then a strictly practical one. > However there is no more practical then a good theory ...right? > > Anyway I wonder if the blockchain method of keeping track of every > node could be applied to a sort of Erlang-blockchain combination? If > every Erlang node would be a blockchain-like supervisor would that > make things unnecessary complicated or is there some potential > stability to gain? I'm not quite sure what you refer to when you say 'blockchain method of keeping track of every node'. Normally a blockchain (as in Bitcoin's architecture) is a Merkle hash tree where the data of a node is hashed together with the hashes of its children asf. until eventually the root of the hash tree is reached. This enables cryptographically secure verification of content and ordering of the data. I do not see how supervision trees would benefit from such a data structure. However, I may misunderstand what your idea is about. Please elaborate further! Kind Regards! Elias > > Just a thought from me > > Best regards > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From skribent_har@REDACTED Sun Sep 25 23:38:31 2016 From: skribent_har@REDACTED (Martin Hedberg) Date: Sun, 25 Sep 2016 21:38:31 +0000 Subject: [erlang-questions] Blockchain and Erlang In-Reply-To: References: , Message-ID: Well... the idea was that each node would have knowledge of events in the past and adjust itself accordingly. If something fails in another end of a system the node would not have to be contacted to change it's behavior. In case a node crash there could be a verified consensus if it should be restarted. The system could perhaps have other priorities. This was just some thoughts from me. Best regards Martin ________________________________ Fr?n: erlang-questions-bounces@REDACTED f?r Elias Rohrer Skickat: den 25 september 2016 22:02 Till: erlang-questions@REDACTED ?mne: Re: [erlang-questions] Blockchain and Erlang Hello Martin, On 25 Sep 2016, at 21:38, Martin Hedberg wrote: > Hi everyone > > This is more of a theoretical question then a strictly practical one. > However there is no more practical then a good theory ...right? > > Anyway I wonder if the blockchain method of keeping track of every > node could be applied to a sort of Erlang-blockchain combination? If > every Erlang node would be a blockchain-like supervisor would that > make things unnecessary complicated or is there some potential > stability to gain? I'm not quite sure what you refer to when you say 'blockchain method of keeping track of every node'. Normally a blockchain (as in Bitcoin's architecture) is a Merkle hash tree where the data of a node is hashed together with the hashes of its children asf. until eventually the root of the hash tree is reached. This enables cryptographically secure verification of content and ordering of the data. I do not see how supervision trees would benefit from such a data structure. However, I may misunderstand what your idea is about. Please elaborate further! Kind Regards! Elias > > Just a thought from me > > Best regards > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions erlang-questions Info Page erlang.org Mailing list for general discussions about Erlang/OTP, the language, implementation, usage, beginners questions, etc... To see the collection of prior postings to the ... _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Sep 26 02:57:08 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 26 Sep 2016 13:57:08 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> It is not clear to me why Erlang document generation would involve any XSLT. Back when XSLT was still newish and I wanted to be a general XMLpert I set out to learn XSLT. One of the exercises I did was to translate the XSLT script that the W3C were then using to turn their documentation format into HTML into Scheme. By the time I had finished translating the sixth page of XSLT into Scheme and still hadn't filled up even one page of Scheme, I decided that XSLT was not for me. No, I would use languages like Scheme, Prolog, Erlang, Haskell, Smalltalk, even on occasion C (yes *C* with a suitable library being shorter and clearer than XSLT), languages that had decent data structures and less inhumane syntax, Now XSL has two parts: the transformation language and the flow objects schema, and I'm not saying anything against XSL-FO. It's just using XSLT to express transformations when we have Erlang that puzzles me. From ok@REDACTED Mon Sep 26 03:09:39 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 26 Sep 2016 14:09:39 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <2e934523-8380-d515-8401-adedd60f50ea@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <2e934523-8380-d515-8401-adedd60f50ea@ninenines.eu> Message-ID: <3baa4e3d-35df-0b5b-e301-ee7d215c36ba@cs.otago.ac.nz> > On 09/23/2016 05:35 PM, Kenneth Lundin wrote: >> I am actually thinking that we don't need PDF at all. HTML should be >> enough. PDF and HTML serve different purposes. For that matter, HTML for a large display and HTML for a small tablet serve different purposes. >> Man pages can also be questioned since they are limiting when it comes >> to format. When I am looking things up in a man page, I couldn't care less about format. I have this little script in $HOME/local/bin/pman #!/bin/sh man -t "$@" | open -f -a /Applications/Preview.app This formats a man page with fancy fonts and opens the result in the usual PDF viewer. Trying to give an honest estimate here, I use 'man' between 10 and 40 times a day. Guess how often I use 'pman'? That's right, almost never. I use 'man' when I need a quick reminder of some detail and I DON'T want to go clickety-scroll-clickety-clickety-scroll-fume-clickety to find stuff and I don't give a pinch of frass for format. Man pages are for *INFORMATION*. Not for brightly coloured advertising leaflets. When I discovered that I could do 'erl -man $MODULE', I was very happy. When do I use 'pman'? Answer: for *long* documents with lots of text I have to slog through to get to the meat. That is, for badly written man pages. Almost the only thing I like about Perl is the way they had the wit to break the Perl documentation into many man-pages. From ok@REDACTED Mon Sep 26 03:17:46 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 26 Sep 2016 14:17:46 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <6760cdf8-290e-9331-4a2e-5aa710f11c31@cs.otago.ac.nz> On 25/09/16 6:50 AM, Robert Virding wrote: > I definitely agree with Lo?c here but from the programmers viewpoint. > When working with the code I need (good) documentation which describes > what the code is doing from the internal POV. I definitely DON'T need > documentation for the user on how to use and what it means and examples > and ... . That just clutters up the page for me writing/maintaining the > code. +1 From ok@REDACTED Mon Sep 26 03:36:48 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 26 Sep 2016 14:36:48 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <80dedc59-a817-6c26-5904-bd2fa840ded7@cs.otago.ac.nz> On 23/09/16 9:17 PM, Lo?c Hoguin wrote: > FYI I am currently working on improving the Cowboy function reference. > My tentative currently looks similar to this for "man > cowboy:start_clear": > https://gist.github.com/essen/3affa1c8e7805a7dc867156b03c1854f - in > HTML/PDF form it would of course have syntax highlighting, proper links > and so on. What I love about this example is that it is the right size. It focuses on one topic. It presents just what I need to know. It provides examples and cross references, and it's STILL not too large. Links are nice. Syntax highlighting is only tolerable if it can be globally turned off, perhaps by auto-generating a version with the highlighting and a version without. > > And this brings us back to one of my points: the *content* is what > matters. Cowboy just moved to the top of my "must study" project list. From ok@REDACTED Mon Sep 26 03:53:57 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 26 Sep 2016 14:53:57 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On 23/09/16 8:36 PM, Lutz Behnke wrote: > I would propose a position specific to the reference documentation: > > 8) Put the documentation in the source code. Use edoc (or similar new > tool). This doesn't work. For why? Because there is necessary documentation which is not about any particular source file. Let's take something outside Erlang as an example. I know, let's take the C library. It is useful to know that if x > 0 then exp(log(x)) is approximately equal to x if |x| <= 709 then log(exp(x)) is approximately equal to x. But neither of these is a fact about log(), so they don't belong in src/libm/src/C/log.c, and neither of these is a fact about exp(), so they don't belong in src/libm/src/C/exp.c either. They belong in a documentation file about the elementary transcendental functions as a group, and there is no one source file corresponding to that. (log.c and exp.c have detailed internal documentation, which users benefit from NOT seeing, except for the accuracy results.) For that matter, log() and clog() aren't even in the same header, yet I would like to see them documented together. Consider using the syntax tools. Any overview or examples you're going to have is likely to span multiple modules. There is no one source file where it would find a uniquely fitting home. If there is no obvious "home" for documentation, it's most likely going nowhere, and that's a bad thing. (For maintenance purposes, I would like to track code changes separately from documentation changes, but that's another issue.) > > And it should a precedent for 3rd party libraries. Java doc/ Doxygen are > fairly good examples for wide spread adoption or integration into other > tools. They are good examples of *adoption*. They are not good examples of *supporting good documentation*. I am sick of getting Doxygen pukes *instead of* documentation. What good is a list of functions to me when I don't yet know what function I need? From lutz.behnke@REDACTED Mon Sep 26 07:40:09 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Mon, 26 Sep 2016 07:40:09 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <9b90c91a-2cda-3b24-9427-061b5ceca21d@informatik.haw-hamburg.de> Am 26.09.2016 um 03:53 schrieb Richard A. O'Keefe: > > > On 23/09/16 8:36 PM, Lutz Behnke wrote: >> I would propose a position specific to the reference documentation: >> >> 8) Put the documentation in the source code. Use edoc (or similar new >> tool). > > This doesn't work. > For why? > Because there is necessary documentation which is not about any > particular source file. > > Let's take something outside Erlang as an example. > I know, let's take the C library. > It is useful to know that > > if x > 0 then exp(log(x)) is approximately equal to x > > if |x| <= 709 then log(exp(x)) is approximately equal to x. I would argue, that's what overview.edoc is for, but I see your point. > > (For maintenance purposes, I would like to track code > changes separately from documentation changes, but that's > another issue.) How do you keep track of source changes making it into doc changes? >> >> And it should a precedent for 3rd party libraries. Java doc/ Doxygen are >> fairly good examples for wide spread adoption or integration into other >> tools. > > They are good examples of *adoption*. They are not good examples > of *supporting good documentation*. I am sick of getting Doxygen > pukes *instead of* documentation. What good is a list of functions to > me when I don't yet know what function I need? Possibly, my level of expectation is so low, that I find almost any published doxygem better that having to pick apart the source drop. If the user doesn't know what he or she needs yet, then reference docs (which I was specifically targetting) are not the right piece of the docs for them. mfg lutz -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany From essen@REDACTED Mon Sep 26 09:38:03 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 26 Sep 2016 09:38:03 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> Message-ID: <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> On 09/26/2016 02:57 AM, Richard A. O'Keefe wrote: > It is not clear to me why Erlang document generation would involve > any XSLT. Typically one can just use the DocBook XSL files (or other tooling, like db2latex) and not have to write their own, or only write a few specific things. But the XSL files in OTP are pretty big, and there's also some pretty big Erlang code around it. I'm not sure why. It's possible that the DocBook tooling wasn't that great when this was first written. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From erlang@REDACTED Mon Sep 26 10:55:24 2016 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 26 Sep 2016 10:55:24 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> Message-ID: On Mon, Sep 26, 2016 at 2:57 AM, Richard A. O'Keefe wrote: > It is not clear to me why Erlang document generation would involve > any XSLT. Back when XSLT was still newish and I wanted to be a > general XMLpert I set out to learn XSLT. One of the exercises I > did was to translate the XSLT script that the W3C were then using > to turn their documentation format into HTML into Scheme. > > By the time I had finished translating the sixth page of XSLT into > Scheme and still hadn't filled up even one page of Scheme, I decided > that XSLT was not for me. No, I would use languages like Scheme, > Prolog, Erlang, Haskell, Smalltalk, even on occasion C (yes *C* > with a suitable library being shorter and clearer than XSLT), > languages that had decent data structures and less inhumane syntax, > > Now XSL has two parts: the transformation language and the flow objects > schema, and I'm not saying anything against XSL-FO. It's just using > XSLT to express transformations when we have Erlang that puzzles me. I agree - the "goodness" comes from XSL-FO not XSLT. Transforming the XML documentation to XSL-FO with an Erlang program is relatively easy - I have done this a few time for my own experimental purposes. The main problem(s) seem to be: - maintaining the transformation program in the future - producing beautiful output for *all* inputs This problem remains irrespective of the programming language used to do the transformations. If the target (XST-FO for Apache fop) is fixed we also need to be aware that Apache-FOP changes with time and is occasionally buggy. So the transformation code needs to work around the bugs and be sometimes written in a non-obvious manner to achieve certain nice formattings. In the 10MB of inputs there will be numerous edge-cases that are not nicely formatted - and things like widows and orphans are never addressed. Conversion to LaTeX is equally difficult - and to HTML leads to CSS hell. Personally I don't care what is used for the transformations - All I require is that the input is validated XML, and the output beautiful PDF - *how* this is done I'd leave up to the programmer. If I was writing the program I'd use Erlang :-) /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lukas@REDACTED Mon Sep 26 10:55:35 2016 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 26 Sep 2016 10:55:35 +0200 Subject: [erlang-questions] all nodes in cluster crashing with eheap_alloc in the same time In-Reply-To: References: Message-ID: Hello, On Wed, Sep 21, 2016 at 7:50 PM, Caragea Silviu wrote: > > The only question I have now is : > > How I can make something to include in the logs more other info before > process dies. like number of messages in the queue. > > We tried to setup also a monitor to be triggered way less than the limit > where it has to be killed: > > Options = [{long_gc, 10000}, {large_heap, 1000000}, busy_port, > busy_dist_port], > erlang:system_monitor(self(), Options), > > handle_info({monitor, Pid, Type, Details}, State) -> > log_system_event({Type, Pid, Details}), > {noreply, State}; > > log_system_event({large_heap, GcPid, Info}) -> > LogFun = fun() -> > case recon:info(GcPid, messages) of > {messages, Messages} -> > ?WARNING_MSG("Large heap (~p): ~p~nProcess info: ~p~nProcess > state size (words in the heap): ~p~nMessage queue(first 10):~p~n", > [GcPid, Info, recon:info(GcPid), erts_debug:size(recon:get_state(GcPid)), > Messages]); > undefined -> > ?WARNING_MSG("Large heap (~p): ~p~nProcess info is not available", > [GcPid, Info]) > end > end, > spawn(LogFun); > > But unfortunately the processes that has this issues have a life time > small than 4 seconds. And this event is never triggered in time. > > Any help is appreciated ! > You could try to use max_heap_size with #{ kill => false } and then install a specialized error_logger that listens to specifically that type of event and retrieves the information you want before killing the process. Depending on how fast you need the run-away process to be killed this may be acceptable to you. Another tip, you may want to configure the process to keep the message queue data off_heap for processes that tend to build large message queues. It will make the GC a lot happiers, but it will also make max_heap_size not include the message queue size when doing it's analysis. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Sep 26 11:16:04 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 26 Sep 2016 11:16:04 +0200 Subject: [erlang-questions] Blockchain and Erlang In-Reply-To: References: Message-ID: On Sun, Sep 25, 2016 at 11:38 PM, Martin Hedberg wrote: > In case a node crash there could be a verified consensus if it should be > restarted. Nodes are automatically restarted in most cases, so there is little consensus needed in the standard case. For pure consensus protocols, Erlang has the advantage you can trust every node, so you don't need a blockchain mechanism for handling it. You can pick among several algorithms: PAXOS and Raft comes to mind, the latter being a structured log as the blockchain, but without the Merkle construction. The other thing to think about is the concept of acceptable latency. In a system like BitCoin, the latency for transaction confirmation is measured in minutes due to the proof of work obligation. In a node-setting, you want such stuff to happen quickly. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Sep 26 11:25:05 2016 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 26 Sep 2016 11:25:05 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> Message-ID: On Mon, Sep 26, 2016 at 9:38 AM, Lo?c Hoguin wrote: > On 09/26/2016 02:57 AM, Richard A. O'Keefe wrote: >> >> It is not clear to me why Erlang document generation would involve >> any XSLT. > > > Typically one can just use the DocBook XSL files (or other tooling, like > db2latex) and not have to write their own, or only write a few specific > things. But the XSL files in OTP are pretty big, and there's also some > pretty big Erlang code around it. I'm not sure why. It's possible that the > DocBook tooling wasn't that great when this was first written. I've used DocBook - I consider it to be total overkill for the Erlang documentation - it's using a battleship to crack a walnut. Straightford XML -> XSL-FO with an Erlang program is really easy the problem is making it look beautiful. It's like making web pages look beautiful - the HTML markup is trivial the CSS is hell. I wrote some crappy looking HTML with my pathetic attempts at prettifying them with a handful of CSS. I got the daft idea of using a CSS framework to "simplify" the process of beautifying my pages. I Googled "small css frameworks" (why small? - because I like to take a quick peek at the code I intend to use and vaguely understand it) What did Google come up with: - 12 Small CSS Frameworks To Use In Your Web Designs - 17 Minimal CSS Frameworks - 10 Lightweight Alternatives To Bootstrap & Foundation - 100+ Best CSS Frameworks for Responsive Design ... Lot's to choose from here :-) A few mouse clicks later and I'm staring at the documentation which *assumes* I know all about sass, grunt, bower, npm, blither, dither bother and blast. Now let's suppose (just suppose) that I chose one of these and tagged up my HTML with the appropriate classes and organised the HTML so it looked beautiful with my chosen framework. Now suppose - horror upon horror that I wanted to *change* frameworks all my carefully tagged up HTML would need re-tagging. This we call progress ... Writing beautiful documentation is very difficult and very time consuming. The text *alone* is difficult - I often rephrase a paragraph many times before I'm happy with it. Beautiful formatting is beyond me. I guess this is why markdown is popular - the Input is simple the output is related to the input in a unpredictable but usually acceptable manner. The output is not beautiful - but probably fit for purpose and good enough. Sorry for the rant - but Every time I try to make my crap html look pretty by waving a bit of CSS at it I get in a bad mood. I am actually a fan of XSL-FO since it has a defined parse tree and the CSS type attributed do actually make sense. The old-timers on this list might remember DSSSL with a mixture of pleasure and horror. CSS seems to be all the bad bits of DSSSL with the good bits omitted. Cheers /Joe > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lukas@REDACTED Mon Sep 26 11:37:36 2016 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 26 Sep 2016 11:37:36 +0200 Subject: [erlang-questions] How to dig why get_tcp/port allocate so much binary memory? In-Reply-To: References: Message-ID: Hello, On Thu, Sep 22, 2016 at 11:41 AM, ??? wrote: > My question is : How can I decrease the drv_binary memory? What parameter > caused the server used so much memory? > Do you have a complete and minimal example of what you are doing? I did not manage to reproduce what you are experiencing using a small program that I wrote. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Sep 26 11:55:08 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 26 Sep 2016 11:55:08 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> Message-ID: <98209ec5-295d-6e34-4425-4c49504a17d2@ninenines.eu> On 09/26/2016 11:25 AM, Joe Armstrong wrote: > On Mon, Sep 26, 2016 at 9:38 AM, Lo?c Hoguin wrote: >> On 09/26/2016 02:57 AM, Richard A. O'Keefe wrote: >>> >>> It is not clear to me why Erlang document generation would involve >>> any XSLT. >> >> >> Typically one can just use the DocBook XSL files (or other tooling, like >> db2latex) and not have to write their own, or only write a few specific >> things. But the XSL files in OTP are pretty big, and there's also some >> pretty big Erlang code around it. I'm not sure why. It's possible that the >> DocBook tooling wasn't that great when this was first written. > > I've used DocBook - I consider it to be total overkill for the Erlang > documentation - it's using a battleship to crack a walnut. > > Straightford XML -> XSL-FO with an Erlang program is really easy > the problem is making it look beautiful. Nobody should use DocBook directly. It's a great intermediary format, not something you should write in. XML is for machines, not for people. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From lukas@REDACTED Mon Sep 26 11:58:21 2016 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 26 Sep 2016 11:58:21 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: Hello, On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice wrote: > Hello, > > To date, this thread has generated quite a few worthwhile insights and > ideas. My fear is that they will be deep-sixed into the archive. On the > other hand, major revision is a daunting task and unlikely to happen. > > But maybe we can focus on specific issues and make iterative headway. > > Fewer than half of the functions in the lists library, for instance, have > code examples. Suppose over the span of one week we were collectively focus > on generating at least two code examples for each function in one library. > > At the end of the week we could organize the submissions and vote on best > candidates for inclusion in the docs. That done, we can pick another module. > > Thus, with not much effort from any one individual, a small posse of > volunteer Erlang wizards could make short work of deficiencies in the docs. > > Anyway, it's an idea. > > All the best, > > LRP > > I think that it is great to see everyone talking about wanting to improve the documentation. The contributions to the Erlang/OTP project that I value that most are documentation changes that make the intention clearer, or explains some corner case somewhere which the docs did not initially mention. Unfortunately, once one has figured out how a function works there seems to be very little incentive to make the docs clearer. I would estimate that about every 20th pull request we get is a documentation fix, and more than half of those are fixes of speling misstakes (which are great!). I've just come back from about two weeks of vacation and this discussion has resulted in roughly 0 pull requests for changes in the documentation. Would it be possible to steer this discussion into doing something instead of talking about doing something? Yes the technology/layout is not perfect, but as Lo?c said, it is the content that matters the most. Lukas // my own oppinions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bog495@REDACTED Mon Sep 26 12:02:46 2016 From: bog495@REDACTED (Bogdan Andu) Date: Mon, 26 Sep 2016 03:02:46 -0700 (PDT) Subject: [erlang-questions] OTP 19.1 compilation fails In-Reply-To: References: Message-ID: <0ba46e67-0c3a-4e27-8fa8-7cff4519da85@googlegroups.com> I propose a diff for a clean compilation $ diff -u /home/andu/otp_src_19.1/erts/emulator/sys/unix/sys.c.orig /home/andu/otp_src_19.1/erts/emulator/sys/unix/sys.c --- /home/andu/otp_src_19.1/erts/emulator/sys/unix/sys.c.orig Mon Sep 26 12:59:49 2016 +++ /home/andu/otp_src_19.1/erts/emulator/sys/unix/sys.c Mon Sep 26 13:00:19 2016 @@ -715,13 +715,13 @@ static RETSIGTYPE suspend_signal(int signum) #endif { - int res, buf[1], __errno = errno; + int res, buf[1], errno_tmp = errno; do { res = read(sig_suspend_fds[0], buf, sizeof(int)); } while (res < 0 && errno == EINTR); /* restore previous errno in case read changed it */ - errno = __errno; + errno = errno_tmp; } #endif /* #ifdef ERTS_SYS_SUSPEND_SIGNAL */ On Monday, September 26, 2016 at 12:31:28 PM UTC+3, Bogdan Andu wrote: > > Hi, > > after applying patches from port/lang/erlang/19/patches > otp 19.1 fails to compile on OpenBSD 5.7/amd64 with error: > > .................... > CC obj/x86_64-unknown-openbsd5.7/opt/smp/sys.o > sys/unix/sys.c: In function 'suspend_signal': > sys/unix/sys.c:718: error: called object '__errno' is not a function > sys/unix/sys.c:721: error: called object '__errno' is not a function > sys/unix/sys.c:724: error: called object '__errno' is not a function > x86_64-unknown-openbsd5.7/Makefile:677: recipe for target 'obj/x86_64-unknown-openbsd5.7/opt/smp/sys.o' failed > gmake[3]: *** [obj/x86_64-unknown-openbsd5.7/opt/smp/sys.o] Error 1 > gmake[3]: Leaving directory '/home/andu/otp_src_19.1/erts/emulator' > /home/andu/otp_src_19.1/make/run_make.mk:35: recipe for target 'opt' failed > gmake[2]: *** [opt] Error 2 > gmake[2]: Leaving directory '/home/andu/otp_src_19.1/erts/emulator' > Makefile:61: recipe for target 'smp' failed > gmake[1]: *** [smp] Error 2 > gmake[1]: Leaving directory '/home/andu/otp_src_19.1/erts' > Makefile:444: recipe for target 'emulator' failed > gmake: *** [emulator] Error 2 > > becsuse in OpenBSD __errno is a function, see: /usr/include/signal.h > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.7/4.2.1/specs > Target: amd64-unknown-openbsd5.7 > Configured with: OpenBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070719 > > $ diff -u /home/andu/otp_src_19.0/erts/emulator/sys/unix/sys.c > /home/andu/otp_src_19.1/erts/emulator/sys/unix/sys.c > --- /home/andu/otp_src_19.0/erts/emulator/sys/unix/sys.c Tue Jun 21 > 21:55:58 2016 > +++ /home/andu/otp_src_19.1/erts/emulator/sys/unix/sys.c Tue Sep 20 > 22:11:23 2016 > @@ -715,11 +715,13 @@ > static RETSIGTYPE suspend_signal(int signum) > #endif > { > - int res; > - int buf[1]; > - do { > - res = read(sig_suspend_fds[0], buf, sizeof(int)); > - } while (res < 0 && errno == EINTR); > + int res, buf[1], __errno = errno; > + do { > + res = read(sig_suspend_fds[0], buf, sizeof(int)); > + } while (res < 0 && errno == EINTR); > + > + /* restore previous errno in case read changed it */ > + errno = __errno; > } > #endif /* #ifdef ERTS_SYS_SUSPEND_SIGNAL */ > > In opt 19.1 is introduced this variable (__errno) which in OpenBSD is a > function. > > > Regards, > /Bogdan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Sep 26 12:29:18 2016 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 26 Sep 2016 12:29:18 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <98209ec5-295d-6e34-4425-4c49504a17d2@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> <98209ec5-295d-6e34-4425-4c49504a17d2@ninenines.eu> Message-ID: On Mon, Sep 26, 2016 at 11:55 AM, Lo?c Hoguin wrote: > On 09/26/2016 11:25 AM, Joe Armstrong wrote: >> >> On Mon, Sep 26, 2016 at 9:38 AM, Lo?c Hoguin wrote: >>> >>> On 09/26/2016 02:57 AM, Richard A. O'Keefe wrote: >>>> >>>> >>>> It is not clear to me why Erlang document generation would involve >>>> any XSLT. >>> >>> >>> >>> Typically one can just use the DocBook XSL files (or other tooling, like >>> db2latex) and not have to write their own, or only write a few specific >>> things. But the XSL files in OTP are pretty big, and there's also some >>> pretty big Erlang code around it. I'm not sure why. It's possible that >>> the >>> DocBook tooling wasn't that great when this was first written. >> >> >> I've used DocBook - I consider it to be total overkill for the Erlang >> documentation - it's using a battleship to crack a walnut. >> >> Straightford XML -> XSL-FO with an Erlang program is really easy >> the problem is making it look beautiful. > > > Nobody should use DocBook directly. It's a great intermediary format, not > something you should write in. > > XML is for machines, not for people. I disagree - Binary formats are for machine. ASCII formats are for people XML is no better or worse than JSON or LISP for precisely entering a parse tree. Editing a well-designed XML data structure in the nxml mode in emacs is really easy. As an *input* to a text processing system XML is great - the alternatives are LaTeX/TeX which has no defined parse tree - and markdown type things which have no defined syntax or semantics and involve a lot of guesswork. You could of course use rich text and a WYSIWY(might)G editor - but then automating things is terrible. My Erlang books start off as XML and editing them is not a problem - formulating the text *is* the problem. /Joe > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang From erlang@REDACTED Mon Sep 26 12:42:57 2016 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 26 Sep 2016 12:42:57 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: I think what I miss most are *examples* I've just been reading the edoc manual pages for a program called (name changed to avoid embarrassment) The functions are well documented - they types are well documented but I haven't a clue about which ORDER to call the functions Imagine a file system. We *document* the open, read, write, and close functions but we don't say you have to open the file before we read it. We dont say when we're done we have to close the file. We don't say this because it is *obvious* But for the module glonk, which exports, zizzle, taddle, glonk and plonk it is NOT obvious. Yes sure you all know you have to call glonk 3 times before calling plonk - but I don't know. Thats why we need examples. Often I search for a tutorial and find a ten line blog posting that actually shows me how to use a library - this gets me started. very short unit tests - placed inline are *very* useful for example: "321" = lists:reverse("123") The unit test *are* the examples - what we don't have is software that parses the code, parses the documentation, parses the unit test and munges all together into a form that is convenient to read. I'm actually trying to write something like this now - hence my wails of anguish over css. Wish me luck /Joe On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson wrote: > Hello, > > On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice > wrote: >> >> Hello, >> >> To date, this thread has generated quite a few worthwhile insights and >> ideas. My fear is that they will be deep-sixed into the archive. On the >> other hand, major revision is a daunting task and unlikely to happen. >> >> But maybe we can focus on specific issues and make iterative headway. >> >> Fewer than half of the functions in the lists library, for instance, have >> code examples. Suppose over the span of one week we were collectively focus >> on generating at least two code examples for each function in one library. >> >> At the end of the week we could organize the submissions and vote on best >> candidates for inclusion in the docs. That done, we can pick another module. >> >> Thus, with not much effort from any one individual, a small posse of >> volunteer Erlang wizards could make short work of deficiencies in the docs. >> >> Anyway, it's an idea. >> >> All the best, >> >> LRP >> > > I think that it is great to see everyone talking about wanting to improve > the documentation. The contributions to the Erlang/OTP project that I value > that most are documentation changes that make the intention clearer, or > explains some corner case somewhere which the docs did not initially > mention. > > Unfortunately, once one has figured out how a function works there seems to > be very little incentive to make the docs clearer. I would estimate that > about every 20th pull request we get is a documentation fix, and more than > half of those are fixes of speling misstakes (which are great!). > > I've just come back from about two weeks of vacation and this discussion has > resulted in roughly 0 pull requests for changes in the documentation. Would > it be possible to steer this discussion into doing something instead of > talking about doing something? Yes the technology/layout is not perfect, but > as Lo?c said, it is the content that matters the most. > > Lukas > // my own oppinions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From kunthar@REDACTED Mon Sep 26 12:45:41 2016 From: kunthar@REDACTED (Gokhan Boranalp) Date: Mon, 26 Sep 2016 13:45:41 +0300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: Greetings, 1. There should be fundamental agreement for classification of the documentation. This discussion is good for me to see who is thinking how about documentation types. 2. To me XSLT is not *enough* to manage all aspects of documentation. We are using sphinx[1] for a large Python project. I have never used it with Erlang but i'll give a try and share results with community. Not every part of the documentation should be done natively in same language. I hope this way is more valuable rather then asking useless additions. [1] http://www.sphinx-doc.org/en/stable/ https://pythonhosted.org/sphinxcontrib-erlangdomain/ On Mon, Sep 26, 2016 at 12:58 PM, Lukas Larsson wrote: > Hello, > > On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice > wrote: >> >> Hello, >> >> To date, this thread has generated quite a few worthwhile insights and >> ideas. My fear is that they will be deep-sixed into the archive. On the >> other hand, major revision is a daunting task and unlikely to happen. >> >> But maybe we can focus on specific issues and make iterative headway. >> >> Fewer than half of the functions in the lists library, for instance, have >> code examples. Suppose over the span of one week we were collectively focus >> on generating at least two code examples for each function in one library. >> >> At the end of the week we could organize the submissions and vote on best >> candidates for inclusion in the docs. That done, we can pick another module. >> >> Thus, with not much effort from any one individual, a small posse of >> volunteer Erlang wizards could make short work of deficiencies in the docs. >> >> Anyway, it's an idea. >> >> All the best, >> >> LRP >> > > I think that it is great to see everyone talking about wanting to improve > the documentation. The contributions to the Erlang/OTP project that I value > that most are documentation changes that make the intention clearer, or > explains some corner case somewhere which the docs did not initially > mention. > > Unfortunately, once one has figured out how a function works there seems to > be very little incentive to make the docs clearer. I would estimate that > about every 20th pull request we get is a documentation fix, and more than > half of those are fixes of speling misstakes (which are great!). > > I've just come back from about two weeks of vacation and this discussion has > resulted in roughly 0 pull requests for changes in the documentation. Would > it be possible to steer this discussion into doing something instead of > talking about doing something? Yes the technology/layout is not perfect, but > as Lo?c said, it is the content that matters the most. > > Lukas > // my own oppinions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- BR, \|/ Kunthar From kenneth@REDACTED Mon Sep 26 14:13:51 2016 From: kenneth@REDACTED (Kenneth Lundin) Date: Mon, 26 Sep 2016 14:13:51 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: ... In your initial comment, you said "If I see a typo", not "if my wife sees a typo" :-) > > I suppose your wife isn't very used to downloading the 240 MBytes, > unpacking them, fixing the file and publishing the change, either. This was > the scenario for which I suggested a simpler alternative. > > There is an even better way, actually, even if it still requires a Github > account in its current form. I don't remember where I saw it first, but I > use it for the erlide documentation (which I am well aware that is lacking > in all other respects): each generated page has at the bottom the message > shown below, where the link opens the source file (markdown, in this case) > from which it was generated in the on-line Github editor. This is something > that could be added to the OTP docs too (but hand-editing Docbook XML is > not as much fun as it sounds like :-\ ) > The XML markup used for the Erlang documentation is not Docbook. We use our own DTDs with much more lightweight markup than Docbook. > > > Did you find errors in the documentation? Do you have improvements to > suggest? Suggest edits! > > > best regards, > Vlad > > > /Kenneth, Erlang/OTP, Ericsson > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rory@REDACTED Mon Sep 26 16:15:21 2016 From: rory@REDACTED (Rory Byrne) Date: Mon, 26 Sep 2016 15:15:21 +0100 Subject: [erlang-questions] {error,closed} vs. {error,econnreset} In-Reply-To: References: <54E4A07E.5010307@erlang.org> <20150502103209.GA19880@nybek.com> <20150624124817.GA30126@nybek.com> Message-ID: <20160926141520.GB2341@nybek.com> Hi Andras, I'm answering this because you addressed my directly. At the current moment I am not in a position to speak with any authority regarding the code in inet_drv.c. It's been over a year since I last looked at this code and it would take me a good few hours to get to a point where I was comfortable to comment on it again. If you sniff the wire and can confirm with absolute certainty that the peer is sending an RST that is getting reported as {error, closed} in Erlang, then I'll make the time to look into it. Needless to say, you would need to provide significantly more information about the scenario in which this occurred: OS where Erlang is running, OS on the peer, all the socket options you set, the exact call(s) where you received {error, closed}, etc. Ideally you'd be able to provide a tcpdump trace of when the connection went down; it wouldn't need to be a deep trace, just enough to see the details of the TCP traffic (flags, sequence numbers, etc). Regards, Rory On Thu, Sep 22, 2016 at 12:51:38PM +0000, Bekes, Andras G wrote: > Hi Rory, All, > > Let me revive this old thread for a minute. The new gen_tcp option {show_econnreset, true} works well. > > However, we still notice some cases when we observe {error,closed} on the Erlang side, but other signs suggest that the TCP connection wasn't intentionally closed by the peer, but was closed because of some error. > We suspect some packets being dropped by the OS due to various buffer overruns. > I am not very familiar with packet-level details of TCP. Can someone confirm if there are other erroneous terminations of a TCP connection (other than econnreset), reported simply as {error,closed} by Erlang? > > I tried checking the code erts/emulator/drivers/common/inet_drv.c and it seems to me not, but can someone actually understanding that code also confirm? > > Thank you very much, > Andras > > -----Original Message----- > From: Bekes, Andras G (ICT) > Sent: Tuesday, August 11, 2015 2:43 PM > To: 'Rory Byrne'; erlang-questions@REDACTED > Subject: RE: [erlang-questions] {error,closed} vs. {error,econnreset} > > Hi Rory, > > I just tested this new feature in Erlang/OTP R18 and it works fine. > > Thank you very much all for implementing it! > > Regards, > Andras > > -----Original Message----- > From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Rory Byrne > Sent: Wednesday, June 24, 2015 2:48 PM > To: erlang-questions@REDACTED > Subject: Re: [erlang-questions] {error,closed} vs. {error,econnreset} > > Hi Andras, > > On Tue, May 05, 2015 at 07:44:47AM +0000, Bekes, Andras G wrote: > > Thank you very much for your efforts Rory. > > > > The ability "to set a socket option that shows all econnreset errors" sounds like the right solution. I am wondering why hiding this detail is the default, but I believe there were good enough reasons to design it that way. > > > > I accept that your solution will not notice the connection reset event in some corner cases. I think this will not apply in my case: I am sending a small amount of data (<1KB) and wait for the reply. > > > > I am looking forward to see your patch in the next release of Erlang/OTP! > > The fix for this is in the 18.0 release. It should take care of the corner cases too. > > Use the socket option '{show_econnreset, true}' and you'll receive {error, econnreset} in passive mode or {tcp_error, Socket, econnreset} in active mode. See the docs [1] for more information. > > Regards, > > Rory > > [1] http://www.erlang.org/doc/man/inet.html#setopts-2 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- From Catenacci@REDACTED Mon Sep 26 16:19:18 2016 From: Catenacci@REDACTED (Onorio Catenacci) Date: Mon, 26 Sep 2016 10:19:18 -0400 Subject: [erlang-questions] [ANN] Chocolatey NuGet Package For Erlang 19.1 Message-ID: Hi all, For those few of us who care :) the Chocolatey NuGet Package for Erlang is now up to OTP 19.1. I would appreciate it if anyone has any feedback please pass it along. Also the Elixir package is up to 1.3.2. I'm planning to get Elixir 1.3.3 up there within the next couple of days and to get Rebar updated to 3.3.1 as well. -- Onorio Catenacci http://onor.io http://www.google.com/+OnorioCatenacci -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Mon Sep 26 16:56:25 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 26 Sep 2016 16:56:25 +0200 Subject: [erlang-questions] gen_statem and multiple timeout vs 1 In-Reply-To: <917841123.4519860.1474824739386@mail.yahoo.com> References: <917841123.4519860.1474824739386.ref@mail.yahoo.com> <917841123.4519860.1474824739386@mail.yahoo.com> Message-ID: <20160926145625.GA42780@erix.ericsson.se> On Sun, Sep 25, 2016 at 05:32:19PM +0000, Vans S wrote: > Learning the new gen_statem made me desire for one extra feature. > > Say you have a common use case of a webserver /w websockets, you have a general connection timeout of 120s, if no messages are received in 120s it means the socket is in an unknown state, and should be closed. > > So you write your returns like this anytime the client sends you a message: > > {next_state, NextState, NewData, {timeout, 120*1000, idle_timeout}} > > Now if the client does not send any messages in 120 seconds, we will get a?idle_timeout?message sent to the gen_statem process. > > Awesome. > > But enter a little complexity, enter websockets. > > Now we need to send a ping from the gen_statem every 15s to the client, but we also need to consider if we did not get any messages from the client in 120s, we are in unknown state and should terminate the connection. > > So now we are just itching to do this on init: > > {ok, initial_state, Data, [? ? ? ? {timeout, 120*1000,?idle_timeout},? ? ? ? {timeout, 15*1000, websocket_ping} > ????]} > > This way we do not need to manage our own timers using erlang:send_after. ?timer module is not even a consideration due to how inefficient it is at scaling. > > But of course we cannot do this, the latest timeout will always override any previous. > > What do you think? Your use case is in the middle ground between the existing event timeout and using erlang:start_timer/4,3, and is a special case of using erlang:start_timer/4,3. The existing {timeout,T,Msg} is an *event* timeout, so you get either an event or the timeout. The timer is cancelled by the first event. This semantics is easy to reason about and has got a fairly simple implementation in the state machine engine partly since it only needs to store one timer ref. It seems you could use a state timeout, i.e the timeout is cancelled when the state changes. This would require the state machine engine to hold any number of timer refs and cancel all during a state change. This semantics is subtly similar to the current event timeout. It would need a new option, e.g {state_timeout,T,Msg}. The {state_timeout,_,_} semantics would be just a special case of using erlang:start_timer/4,3, keep your timer ref in the server state and cancel it when needed, since in the general case you might want to cancel the timer at some other state change or maybe not a state change but an event. So the question is if a {state_timeout,_,_} feature that auto cancels the timer at the first state change is so useful that it is worthy of being implemented? It is not _that_ much code that is needed to store a timer ref and cancel the timer started with erlang:start_timer/4,3, and it is more flexible. I implemented the {timeout,_,_} feature just so make it easy to port from gen_fsm. Otherwise I thought that using explicit timers was easy enough. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From lloyd@REDACTED Mon Sep 26 17:57:26 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 26 Sep 2016 11:57:26 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <1474905446.24042506@apps.rackspace.com> +1 LRP -----Original Message----- From: "Lukas Larsson" Sent: Monday, September 26, 2016 5:58am To: "Lloyd R. Prentice" Cc: "Roger Lipscombe" , "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal Hello, On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice wrote: > Hello, > > To date, this thread has generated quite a few worthwhile insights and > ideas. My fear is that they will be deep-sixed into the archive. On the > other hand, major revision is a daunting task and unlikely to happen. > > But maybe we can focus on specific issues and make iterative headway. > > Fewer than half of the functions in the lists library, for instance, have > code examples. Suppose over the span of one week we were collectively focus > on generating at least two code examples for each function in one library. > > At the end of the week we could organize the submissions and vote on best > candidates for inclusion in the docs. That done, we can pick another module. > > Thus, with not much effort from any one individual, a small posse of > volunteer Erlang wizards could make short work of deficiencies in the docs. > > Anyway, it's an idea. > > All the best, > > LRP > > I think that it is great to see everyone talking about wanting to improve the documentation. The contributions to the Erlang/OTP project that I value that most are documentation changes that make the intention clearer, or explains some corner case somewhere which the docs did not initially mention. Unfortunately, once one has figured out how a function works there seems to be very little incentive to make the docs clearer. I would estimate that about every 20th pull request we get is a documentation fix, and more than half of those are fixes of speling misstakes (which are great!). I've just come back from about two weeks of vacation and this discussion has resulted in roughly 0 pull requests for changes in the documentation. Would it be possible to steer this discussion into doing something instead of talking about doing something? Yes the technology/layout is not perfect, but as Lo?c said, it is the content that matters the most. Lukas // my own oppinions From lloyd@REDACTED Mon Sep 26 18:41:40 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 26 Sep 2016 12:41:40 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <1474908100.763928884@apps.rackspace.com> Joe, You've said so well what I've been trying to harp on. My most recent timesink has been trying to understand xmerl sufficiently well to pull book data out of several different book APIs. Dave Thomas's 2007 tutorial has been a big help, but the black holes in my understanding still significantly impede my progress. So far I've spent maybe 10 to 15 hours trying to scope it out. I can get much of what I need from Amazon's APIs, but I need a redundant source. The Library of Congress API completely eludes me; I get a little further with ISBNdb, but still not far enough. Given discussion on the documentation thread to date, it seems to me that there are four issues at stake: 1) Content deficiencies 2) Formatting issues 3) Lack of consensus of what we, as a community, want 4) How we move forward toward comprehensive improvement of documentation. Lukas Larsson's most recent post makes a good point. Bruce Yinhe tells me in a private post that his group is about to hire one person on a part-time basis to work on documentation improvements. I've lost it in the thread, but as I recall we had some promising interest in documentation improvements from an Erricson employee. It would be great if we could begin to rally around these comments and find some kind of convergence toward progress. My take is to break the large task down into small chunks, bring the intelligence and resources of the community to bear on one specific issue at a time and, and get it done. I don't have the technical chops, but I'll gladly work with you or anyone else to address content issues on a module-by-module basis. I can ask Micky-the_Dunce questions and, perhaps, help clarify language. It would be great if you could help clarify intent and application issues. All the best, Lloyd -----Original Message----- From: "Joe Armstrong" Sent: Monday, September 26, 2016 6:42am To: "Lukas Larsson" Cc: "Lloyd R. Prentice" , "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal I think what I miss most are *examples* I've just been reading the edoc manual pages for a program called (name changed to avoid embarrassment) The functions are well documented - they types are well documented but I haven't a clue about which ORDER to call the functions Imagine a file system. We *document* the open, read, write, and close functions but we don't say you have to open the file before we read it. We dont say when we're done we have to close the file. We don't say this because it is *obvious* But for the module glonk, which exports, zizzle, taddle, glonk and plonk it is NOT obvious. Yes sure you all know you have to call glonk 3 times before calling plonk - but I don't know. Thats why we need examples. Often I search for a tutorial and find a ten line blog posting that actually shows me how to use a library - this gets me started. very short unit tests - placed inline are *very* useful for example: "321" = lists:reverse("123") The unit test *are* the examples - what we don't have is software that parses the code, parses the documentation, parses the unit test and munges all together into a form that is convenient to read. I'm actually trying to write something like this now - hence my wails of anguish over css. Wish me luck /Joe On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson wrote: > Hello, > > On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice > wrote: >> >> Hello, >> >> To date, this thread has generated quite a few worthwhile insights and >> ideas. My fear is that they will be deep-sixed into the archive. On the >> other hand, major revision is a daunting task and unlikely to happen. >> >> But maybe we can focus on specific issues and make iterative headway. >> >> Fewer than half of the functions in the lists library, for instance, have >> code examples. Suppose over the span of one week we were collectively focus >> on generating at least two code examples for each function in one library. >> >> At the end of the week we could organize the submissions and vote on best >> candidates for inclusion in the docs. That done, we can pick another module. >> >> Thus, with not much effort from any one individual, a small posse of >> volunteer Erlang wizards could make short work of deficiencies in the docs. >> >> Anyway, it's an idea. >> >> All the best, >> >> LRP >> > > I think that it is great to see everyone talking about wanting to improve > the documentation. The contributions to the Erlang/OTP project that I value > that most are documentation changes that make the intention clearer, or > explains some corner case somewhere which the docs did not initially > mention. > > Unfortunately, once one has figured out how a function works there seems to > be very little incentive to make the docs clearer. I would estimate that > about every 20th pull request we get is a documentation fix, and more than > half of those are fixes of speling misstakes (which are great!). > > I've just come back from about two weeks of vacation and this discussion has > resulted in roughly 0 pull requests for changes in the documentation. Would > it be possible to steer this discussion into doing something instead of > talking about doing something? Yes the technology/layout is not perfect, but > as Lo?c said, it is the content that matters the most. > > Lukas > // my own oppinions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bildeyko@REDACTED Mon Sep 26 18:24:07 2016 From: bildeyko@REDACTED (Nikolay Bildeyko) Date: Mon, 26 Sep 2016 19:24:07 +0300 Subject: [erlang-questions] Error: Node is not running In-Reply-To: References: Message-ID: On 25 Sep 2016 09:06:49, Grzegorz Junka wrote: > That usually happens when you start the node with -name (indicating a > long name) where the name isn't a valid FQDN (isn't properly resolved by > DNS). How do you supply the name of the node, with -name or -sname? If > the former, can you resolve that name to IP with dig or drill? I supplied the name with -name. -sname helped me. Thanks. Cheers, Nikolay Bildeyko From marco.molteni@REDACTED Mon Sep 26 20:01:58 2016 From: marco.molteni@REDACTED (Marco Molteni) Date: Mon, 26 Sep 2016 20:01:58 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> Message-ID: <62A45CDF-5FED-4AD6-AA5B-CE82797C4813@laposte.net> my suggestion for the documentation format is asciidoc. Almost as simple as markdown but more powerful, simpler than rST. As readable as markdown. And it is the only format I ever found that allowed me to avoid LaTeX (been there, done that for my thesis) and the dreaded XML / DocBook / FOP madness. In particular, the modern asciidoctor to generate HTML, and asciidoctor-pdf to generate PDF. It is also directly supported by github, any foo.adoc file will be rendered (as is the case for any foo.md). http://asciidoctor.org/ marco From vladdu55@REDACTED Mon Sep 26 20:28:36 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 26 Sep 2016 20:28:36 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: Following the call for doing something rather than talking about it, I went on looking a little at the docs in more detail (to see if there is some low-hanging fruit) and I have a few comments and questions. The generated HTML can be improved by making it HTML5. This means that it would have more semantic tags and structure, closer to the original XML. This would make it easier to consume the HTML in other tools (are there any? I do it in erlide, if the XML sources aren't available) and also to write reasonably simple CSS for it. On the other hand, if tools already use the HTML, they would need to use different parsers for different OTP versions... As the HTML looks today, it is basically impossible to style nicely. For example: the html contains formatting-related tags (
) and class names (bold_code); lists look alike (no classes nor ids); enumerations aren't structured as lists nor are they structured (the functions in a module are just a sequence of

with some of them having certain classes, for example); headers are not always hierarchical. Would that be something useful to look at and improve? It's not as useful as improving the content, but it can improve the reading experience. I saw someone suggesting AsciiDoc. That is a nice language, better than Markdown. I don't know how inclined the OTP team is towards replacing the XML sources, but I believe that an example of a page would help a lot. I will try to convert a module's docs to "better" HTML and AsciiDoc, let's see what that gives! best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Sep 26 20:39:32 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 26 Sep 2016 20:39:32 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: On 09/26/2016 08:28 PM, Vlad Dumitrescu wrote: > I saw someone suggesting AsciiDoc. That is a nice language, better than > Markdown. I don't know how inclined the OTP team is towards replacing > the XML sources, but I believe that an example of a page would help a lot. > > I will try to convert a module's docs to "better" HTML and AsciiDoc, > let's see what that gives! FYI following this thread I started updating the Cowboy documentation to be more user friendly with one page per function, examples etc. and the first converted module can be found here: https://github.com/ninenines/cowboy/commit/04247240629f1b9807feca34fde6de89286d4774 Could be used as inspiration. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From erlang@REDACTED Mon Sep 26 22:03:15 2016 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 26 Sep 2016 22:03:15 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <1474908100.763928884@apps.rackspace.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: Regarding the documentation - there is a step0 that needs to be done *before* attacking the document improvement problem. The following things are needed (I my opinion) 1) The number of DTDs in the documentation should be reduced to ONE there are currently 26 these are in otp_src_/lib/erl_docgen/priv/dtd 2) tags that are used infrequently should be removed and the source XML corrected. Some tags are virtually *never* used. 3) All XML files should validate with the new DTD These steps need quite a lot of work ... 4) The Erlang parser should be changed to exactly reproduce the source. Right now the parse tree of correct erlang has all the comments and white space removed. I'd suggest attaching the comments to the next following token (for example {atom,Line,theAtom} should become {atom, Line, theAtom, "the preceding comments and white space"} It should be possible to *exactly* reconstruct the input from the parse tree.

5) We should decide how to attach "floating" comments in the source. Does a comment *before* a function apply to the next function or not? 6) We need some "injection" API to inject code, meta-data, examples and documentations into a data base. For example inject:code("foo.erl") should inject a load of key/value pairs into a data base, with something like the following keys {text, Mod,Func,Arity} => the source code text {spec, Mod, Func, Arity} => the spec {doc, Mod,Func,Arity} => the documentation {examples,Mod,Func,Arity} = [Examples] The entities in the database should be sufficient to reconstruct the original text, and perform various analysis of the functions. I think *most* of the problems involved are due to the difficulty of extracting information from the source files and editing this when it is wrong. I'm currently trying to do parts of this. A "relatively simple" program should be able to (for a given function) - find the exact source text - find all old versions - find the specs and types referred to - find the documentation - find the test cases Doing so involves analysing the erlang sources the XML sources and the test cases, and involves a deal of guess work. All this must be done on a moving target and should not break the existing system. I suspect that the code to accurately manipulate the code and documentation have been has been written several times in different projects (for example the wrangler, and the Eclipse interface) both need to manipulate the source in various ways. On Mon, Sep 26, 2016 at 6:41 PM, wrote: > Joe, > > You've said so well what I've been trying to harp on. > > My most recent timesink has been trying to understand xmerl sufficiently well to pull book data out of several different book APIs. Dave Thomas's 2007 tutorial has been a big help, but the black holes in my understanding still significantly impede my progress. So far I've spent maybe 10 to 15 hours trying to scope it out. I can get much of what I need from Amazon's APIs, but I need a redundant source. The Library of Congress API completely eludes me; I get a little further with ISBNdb, but still not far enough. > > Given discussion on the documentation thread to date, it seems to me that there are four issues at stake: > > 1) Content deficiencies > 2) Formatting issues > 3) Lack of consensus of what we, as a community, want > 4) How we move forward toward comprehensive improvement of documentation. > > Lukas Larsson's most recent post makes a good point. > > Bruce Yinhe tells me in a private post that his group is about to hire one person on a part-time basis to work on documentation improvements. > > I've lost it in the thread, but as I recall we had some promising interest in documentation improvements from an Erricson employee. > > It would be great if we could begin to rally around these comments and find some kind of convergence toward progress. > > My take is to break the large task down into small chunks, bring the intelligence and resources of the community to bear on one specific issue at a time and, and get it done. I think many (most) of the problems arise because what we are ultimately doing is changing the content of a file at some place. Fixing a typo/bug involves 1- finding the appropriate file 2 - changing the file at the appropriate place 3 - updating the file (somehow) 4 - generating the downstream documents that depend upon the file All these steps are difficult We can imagine a simpler way: Suppose a file is a sequence of paragraphs. Each paragraph has a GUId In (say) HTML

This is my paragarph ...

If I want to update the paragraphs I just send a message {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" "the new content"} to some server - this should be checked (manually) and then if approved used to update everything. In other threads I have argued that *everything* should be in a global database with a huge DHT tracking where things are. A key to "changing things" is "naming things" and "finding things" yes another (even simpler) alternative is to have a message {change,SHA,NewText} Meaning "change the paragraph with sha1 checksum to " Implementing this is easy - BUT all paragraphs with the same SHA would be changed - which might not be what we want. I have (incidentally) experimented with this - tagging all paragraphs with their SHAs and sticking the results in a database. make a server that accepts messages of the form {change, , } The server finds a paragraph with sha1 checksum and changes it to - it changes the appropriate file in a GIT archive does all the /add/commit/push magic and the job is done. (I think I'll implement this for fun :-) > > I don't have the technical chops, but I'll gladly work with you or anyone else to address content issues on a module-by-module basis. I can ask Micky-the_Dunce questions and, perhaps, help clarify language. It would be great if you could help clarify intent and application issues. > > All the best, > > Lloyd > > > > > > > > > -----Original Message----- > From: "Joe Armstrong" > Sent: Monday, September 26, 2016 6:42am > To: "Lukas Larsson" > Cc: "Lloyd R. Prentice" , "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal > > I think what I miss most are *examples* > > I've just been reading the edoc manual pages for a program > called (name changed to avoid embarrassment) > > The functions are well documented - they types are well documented > but I haven't a clue about which ORDER to call the functions > > Imagine a file system. > > We *document* the open, read, write, and close functions > but we don't say you have to open the file before we read it. > We dont say when we're done we have to close the file. > > We don't say this because it is *obvious* > > But for the module glonk, which exports, zizzle, taddle, glonk and plonk > it is NOT obvious. Yes sure you all know you have to call glonk 3 times > before calling plonk - but I don't know. > > Thats why we need examples. > > Often I search for a tutorial and find a ten line blog posting that > actually shows me how to use a library - this gets me started. > > very short unit tests - placed inline are *very* useful > > for example: > > "321" = lists:reverse("123") > > The unit test *are* the examples - what we don't have is software that > parses the code, parses the documentation, parses the unit test > and munges all together into a form that is convenient to read. > > I'm actually trying to write something like this now - hence my wails > of anguish over css. > > Wish me luck > > /Joe > > > > > > > > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson wrote: >> Hello, >> >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice >> wrote: >>> >>> Hello, >>> >>> To date, this thread has generated quite a few worthwhile insights and >>> ideas. My fear is that they will be deep-sixed into the archive. On the >>> other hand, major revision is a daunting task and unlikely to happen. >>> >>> But maybe we can focus on specific issues and make iterative headway. >>> >>> Fewer than half of the functions in the lists library, for instance, have >>> code examples. Suppose over the span of one week we were collectively focus >>> on generating at least two code examples for each function in one library. >>> >>> At the end of the week we could organize the submissions and vote on best >>> candidates for inclusion in the docs. That done, we can pick another module. >>> >>> Thus, with not much effort from any one individual, a small posse of >>> volunteer Erlang wizards could make short work of deficiencies in the docs. >>> >>> Anyway, it's an idea. >>> >>> All the best, >>> >>> LRP >>> >> >> I think that it is great to see everyone talking about wanting to improve >> the documentation. The contributions to the Erlang/OTP project that I value >> that most are documentation changes that make the intention clearer, or >> explains some corner case somewhere which the docs did not initially >> mention. >> >> Unfortunately, once one has figured out how a function works there seems to >> be very little incentive to make the docs clearer. I would estimate that >> about every 20th pull request we get is a documentation fix, and more than >> half of those are fixes of speling misstakes (which are great!). >> >> I've just come back from about two weeks of vacation and this discussion has >> resulted in roughly 0 pull requests for changes in the documentation. Would >> it be possible to steer this discussion into doing something instead of >> talking about doing something? Yes the technology/layout is not perfect, but >> as Lo?c said, it is the content that matters the most. >> >> Lukas >> // my own oppinions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > From vladdu55@REDACTED Mon Sep 26 22:49:03 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 26 Sep 2016 22:49:03 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: Hi Joe, On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: > 4) The Erlang parser should be changed to exactly > reproduce the source. > Right now the parse tree of correct erlang has all the comments > and white space removed. I'd suggest attaching the comments to the > next following token (for example {atom,Line,theAtom} should become > {atom, Line, theAtom, "the preceding comments and white space"} > It should be possible to *exactly* reconstruct the input from the parse > tree. > > > This is what I set out to implement with 'sourcer' ( https://github.com/erlang/sourcer). I am actually aiming even higher: keep track of macros and -ifdefs and the possibly different structure of a module when considering them. Also, I want to be able to parse code that is in the process of being edited (only possible if knowing the latest parseable state of the file). On the bright side, this parser need not replace erl_parse. The compiler and most tools don't need all this extra detail. It would be good to be able to not implement _everything_ from scratch, but I couldn't find a way to do all this than with a hand-written parser. Ideas, feedback, suggestions, improvements and rotten tomatoes are welcome. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Sep 26 22:51:32 2016 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 26 Sep 2016 22:51:32 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: Hello Joe, What you are talking about is about lowering the cost of entry when doing documentation updates. This is a great effort and one which we should really pursue, but as you say it is a lot of work. Is there really a *need* for that to be in place first? Can't there be lots of smaller parallel efforts (we as Erlang programmers should be familiar with the concept) that improve the content at the same time? Since I'm preaching action rather than discussions, it would hypocritical of me to not do anything so I've submitted a PR with a documentation change that I believe will make binary_to_term/1 a little clearer for anyone wondering how to use it for the first time: https://github.com/erlang/otp/pull/1181 Lukas On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: > Regarding the documentation - there is a step0 that needs to be done > *before* attacking the document improvement problem. > > The following things are needed (I my opinion) > > 1) The number of DTDs in the documentation should be reduced to ONE > there are currently 26 these are in > otp_src_/lib/erl_docgen/priv/dtd > > 2) tags that are used infrequently should be removed and the source XML > corrected. Some tags are virtually *never* used. > > 3) All XML files should validate with the new DTD > > These steps need quite a lot of work ... > > 4) The Erlang parser should be changed to exactly > reproduce the source. > Right now the parse tree of correct erlang has all the comments > and white space removed. I'd suggest attaching the comments to the > next following token (for example {atom,Line,theAtom} should become > {atom, Line, theAtom, "the preceding comments and white space"} > It should be possible to *exactly* reconstruct the input from the parse > tree. > > > > > > > > 5) We should decide how to attach "floating" comments in the source. > Does a comment *before* a function apply to the next function or not? > > 6) We need some "injection" API to inject code, meta-data, examples > and documentations into a data base. > > For example inject:code("foo.erl") should inject a load of key/value > pairs into a data base, with something like the following keys > > {text, Mod,Func,Arity} => the source code text > {spec, Mod, Func, Arity} => the spec > {doc, Mod,Func,Arity} => the documentation > {examples,Mod,Func,Arity} = [Examples] > > The entities in the database should be sufficient to reconstruct the > original text, and perform various analysis of the functions. > > I think *most* of the problems involved are due to the difficulty of > extracting information from the source files and editing this when it is > wrong. > > I'm currently trying to do parts of this. > > A "relatively simple" program should be able to (for a given function) > > - find the exact source text > - find all old versions > - find the specs and types referred to > - find the documentation > - find the test cases > > Doing so involves analysing the erlang sources the XML sources and the > test cases, and involves a deal of guess work. > > All this must be done on a moving target and should not break the > existing system. > > I suspect that the code to accurately manipulate the code and > documentation have been has been written several times in different > projects (for example > the wrangler, and the Eclipse interface) both need to manipulate the source > in various ways. > > > > > On Mon, Sep 26, 2016 at 6:41 PM, wrote: > > Joe, > > > > You've said so well what I've been trying to harp on. > > > > My most recent timesink has been trying to understand xmerl sufficiently > well to pull book data out of several different book APIs. Dave Thomas's > 2007 tutorial has been a big help, but the black holes in my understanding > still significantly impede my progress. So far I've spent maybe 10 to 15 > hours trying to scope it out. I can get much of what I need from Amazon's > APIs, but I need a redundant source. The Library of Congress API completely > eludes me; I get a little further with ISBNdb, but still not far enough. > > > > Given discussion on the documentation thread to date, it seems to me > that there are four issues at stake: > > > > 1) Content deficiencies > > 2) Formatting issues > > 3) Lack of consensus of what we, as a community, want > > 4) How we move forward toward comprehensive improvement of documentation. > > > > Lukas Larsson's most recent post makes a good point. > > > > Bruce Yinhe tells me in a private post that his group is about to hire > one person on a part-time basis to work on documentation improvements. > > > > I've lost it in the thread, but as I recall we had some promising > interest in documentation improvements from an Erricson employee. > > > > It would be great if we could begin to rally around these comments and > find some kind of convergence toward progress. > > > > My take is to break the large task down into small chunks, bring the > intelligence and resources of the community to bear on one specific issue > at a time and, and get it done. > > I think many (most) of the problems arise because what we are ultimately > doing is changing the content of a file at some place. > > Fixing a typo/bug involves > > 1- finding the appropriate file > 2 - changing the file at the appropriate place > 3 - updating the file (somehow) > 4 - generating the downstream documents that depend upon the file > > All these steps are difficult > > We can imagine a simpler way: > > Suppose a file is a sequence of paragraphs. Each paragraph > has a GUId > > In (say) HTML > >

> This is my paragarph ... >

> > If I want to update the paragraphs I just send a message > > {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" > "the new content"} > > to some server - this should be checked (manually) and then > if approved used to update everything. > > In other threads I have argued that *everything* should be in a global > database with a huge DHT tracking where things are. > > A key to "changing things" is "naming things" and "finding things" > > yes another (even simpler) alternative is to have a message > > {change,SHA,NewText} > > Meaning "change the paragraph with sha1 checksum to " > > Implementing this is easy - BUT all paragraphs with the same SHA > would be changed - which might not be what we want. > > I have (incidentally) experimented with this - tagging all paragraphs > with their SHAs and sticking the results in a database. > > > make a server that accepts messages of the form > > {change, , } > > The server finds a paragraph with sha1 checksum and changes > it to - it changes the appropriate file in a GIT archive > does all the /add/commit/push magic and the job is done. > > (I think I'll implement this for fun :-) > > > > > > > I don't have the technical chops, but I'll gladly work with you or > anyone else to address content issues on a module-by-module basis. I can > ask Micky-the_Dunce questions and, perhaps, help clarify language. It would > be great if you could help clarify intent and application issues. > > > > All the best, > > > > Lloyd > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: "Joe Armstrong" > > Sent: Monday, September 26, 2016 6:42am > > To: "Lukas Larsson" > > Cc: "Lloyd R. Prentice" , " > erlang-questions@REDACTED" > > Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal > > > > I think what I miss most are *examples* > > > > I've just been reading the edoc manual pages for a program > > called (name changed to avoid embarrassment) > > > > The functions are well documented - they types are well documented > > but I haven't a clue about which ORDER to call the functions > > > > Imagine a file system. > > > > We *document* the open, read, write, and close functions > > but we don't say you have to open the file before we read it. > > We dont say when we're done we have to close the file. > > > > We don't say this because it is *obvious* > > > > But for the module glonk, which exports, zizzle, taddle, glonk and plonk > > it is NOT obvious. Yes sure you all know you have to call glonk 3 times > > before calling plonk - but I don't know. > > > > Thats why we need examples. > > > > Often I search for a tutorial and find a ten line blog posting that > > actually shows me how to use a library - this gets me started. > > > > very short unit tests - placed inline are *very* useful > > > > for example: > > > > "321" = lists:reverse("123") > > > > The unit test *are* the examples - what we don't have is software that > > parses the code, parses the documentation, parses the unit test > > and munges all together into a form that is convenient to read. > > > > I'm actually trying to write something like this now - hence my wails > > of anguish over css. > > > > Wish me luck > > > > /Joe > > > > > > > > > > > > > > > > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson > wrote: > >> Hello, > >> > >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice < > lloyd@REDACTED> > >> wrote: > >>> > >>> Hello, > >>> > >>> To date, this thread has generated quite a few worthwhile insights and > >>> ideas. My fear is that they will be deep-sixed into the archive. On the > >>> other hand, major revision is a daunting task and unlikely to happen. > >>> > >>> But maybe we can focus on specific issues and make iterative headway. > >>> > >>> Fewer than half of the functions in the lists library, for instance, > have > >>> code examples. Suppose over the span of one week we were collectively > focus > >>> on generating at least two code examples for each function in one > library. > >>> > >>> At the end of the week we could organize the submissions and vote on > best > >>> candidates for inclusion in the docs. That done, we can pick another > module. > >>> > >>> Thus, with not much effort from any one individual, a small posse of > >>> volunteer Erlang wizards could make short work of deficiencies in the > docs. > >>> > >>> Anyway, it's an idea. > >>> > >>> All the best, > >>> > >>> LRP > >>> > >> > >> I think that it is great to see everyone talking about wanting to > improve > >> the documentation. The contributions to the Erlang/OTP project that I > value > >> that most are documentation changes that make the intention clearer, or > >> explains some corner case somewhere which the docs did not initially > >> mention. > >> > >> Unfortunately, once one has figured out how a function works there > seems to > >> be very little incentive to make the docs clearer. I would estimate that > >> about every 20th pull request we get is a documentation fix, and more > than > >> half of those are fixes of speling misstakes (which are great!). > >> > >> I've just come back from about two weeks of vacation and this > discussion has > >> resulted in roughly 0 pull requests for changes in the documentation. > Would > >> it be possible to steer this discussion into doing something instead of > >> talking about doing something? Yes the technology/layout is not > perfect, but > >> as Lo?c said, it is the content that matters the most. > >> > >> Lukas > >> // my own oppinions > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Sep 26 23:49:13 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 27 Sep 2016 10:49:13 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <9b90c91a-2cda-3b24-9427-061b5ceca21d@informatik.haw-hamburg.de> References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <9b90c91a-2cda-3b24-9427-061b5ceca21d@informatik.haw-hamburg.de> Message-ID: <21d16e06-6b49-ba73-cb6f-517e16b131c5@cs.otago.ac.nz> On 26/09/16 6:40 PM, Lutz Behnke wrote: >> (For maintenance purposes, I would like to track code >> changes separately from documentation changes, but that's >> another issue.) > > How do you keep track of source changes making it into doc changes? I don't understand the question. If you are talking about a change to the source code that has a corresponding (but necessarily different) change to the documentation, then they form a single commit with a common MR or other identifier (if such are used). > > Possibly, my level of expectation is so low, that I find almost any > published doxygem better that having to pick apart the source drop. > > If the user doesn't know what he or she needs yet, then reference docs > (which I was specifically targetting) are not the right piece of the > docs for them. I was thinking of a number of fairly popular open source projects where there was a sketchy tutorial and then a Doxygen puke (with many of the functions uncommented, just automatic headers) *instead* of documentation. Actually, if you look at source code, there are often cues to be had from the words inside the functions. I guess it depends on what you mean by "published Doxygen". I was meaning "so-called documentation made available to people outside the project generated using Doxygen." BTW: I am painfully aware that my own documentation skills leave much to be desired. From ok@REDACTED Mon Sep 26 23:56:55 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 27 Sep 2016 10:56:55 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> <98209ec5-295d-6e34-4425-4c49504a17d2@ninenines.eu> Message-ID: On 26/09/16 11:29 PM, Joe Armstrong wrote: > As an *input* to a text processing system XML is great - the alternatives > are LaTeX/TeX which has no defined parse tree - and markdown type things > which have no defined syntax or semantics and involve a lot of guesswork. TeX's greatest failing is that it's a Turing-complete programming language. That means processing it by anything other than TeX is pretty much out of the question. There is a document formatter which has, or could have, a defined parse tree, and that's Lout. https://en.wikipedia.org/wiki/Lout_(software) Lout picked up the idea of declarative documents from SCRIBE. From jose.valim@REDACTED Tue Sep 27 00:17:27 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Tue, 27 Sep 2016 01:17:27 +0300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <21d16e06-6b49-ba73-cb6f-517e16b131c5@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <9b90c91a-2cda-3b24-9427-061b5ceca21d@informatik.haw-hamburg.de> <21d16e06-6b49-ba73-cb6f-517e16b131c5@cs.otago.ac.nz> Message-ID: > I guess it depends on what you mean by "published Doxygen". > I was meaning "so-called documentation made available to people outside > the project generated using Doxygen." > I believe one of the main issues with projects like Doxygen is that they don't make a strong distinction syntax-wise between documentation and code comments. After all, the two have different targets: the former is for users of your API, the latter is for readers of your code. And without having a strong distinction between the two, programmers do not find themselves in the proper mindset when writing documentation. They write documentation as if developers were also reading the source code which is the opposite of what documentation is meant to be. That's why I dislike the term "doc comments". Is it documentation or is it a comment? I have also seen similar confusion in the Ruby community, where there isn't also a strong distinction between code comment and documentation. I have heard developers saying "code should be self-documenting" as a justification for not writing documentation while they probably meant that "code should be self-explanatory" to imply that excessive code comments may be a code smell, such as: # Removes the discount from the tag price final_price = tag_price - discount Some languages however, like Python and Clojure, do allow documentation to be written alongside the source, but they have a strong distinction between what is documentation and what is a code comment. They also make that documentation part of the function reflection API, making it easy to retrieve and format that documentation, even in the language repl. In any case, reference documentation is only one of aspect of writing documentation. Regardless if the reference documentation is written at the source or separately, most libraries also need at least one guide/tutorial/free-form introduction. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Tue Sep 27 00:58:53 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Mon, 26 Sep 2016 15:58:53 -0700 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <1474908100.763928884@apps.rackspace.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: On 09/26/2016 09:41 AM, lloyd@REDACTED wrote: > My most recent timesink has been trying to understand xmerl... If you have an XML schema file, erlsom can be run in "data binder" mode which will create a nice Erlang record out of a well-formed XML document: https://github.com/willemdj/erlsom As part of this mode of operation, erlsom can also process the XML schema file and create a hrl file containing the record definition. I found this _much_ easier to work with than what xmerl offers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From be.dmitry@REDACTED Tue Sep 27 01:10:13 2016 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Tue, 27 Sep 2016 09:10:13 +1000 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> Message-ID: <95FF9FA8-6E52-46C5-A684-41AEFB04116C@gmail.com> On 26 September 2016 11:53:57 GMT+10:00, "Richard A. O'Keefe" wrote: > > if x > 0 then exp(log(x)) is approximately equal to x > > if |x| <= 709 then log(exp(x)) is approximately equal to x. > >But neither of these is a fact about log(), so they don't belong >in src/libm/src/C/log.c, and neither of these is a fact about >exp(), so they don't belong in src/libm/src/C/exp.c either. >They belong in a documentation file about the elementary >transcendental functions as a group, and there is no one source >file corresponding to that. (log.c and exp.c have detailed >internal documentation, which users benefit from NOT seeing, >except for the accuracy results.) > >For that matter, log() and clog() aren't even in the same >header, yet I would like to see them documented together. > The documentation and proofs for these properties would go into tests. The tools should support documentation extraction from test modules. This has a benefit when properties change the tests have to also be updated along with the documentation. From lloyd@REDACTED Tue Sep 27 01:33:01 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 26 Sep 2016 19:33:01 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: <1474932781.535314703@apps.rackspace.com> I'm hearing the sound of progress. Cheers to all! Let me know if I can help with dog work within my technical limits. LRP -----Original Message----- From: "Lukas Larsson" Sent: Monday, September 26, 2016 4:51pm To: "Joe Armstrong" Cc: "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions Hello Joe, What you are talking about is about lowering the cost of entry when doing documentation updates. This is a great effort and one which we should really pursue, but as you say it is a lot of work. Is there really a *need* for that to be in place first? Can't there be lots of smaller parallel efforts (we as Erlang programmers should be familiar with the concept) that improve the content at the same time? Since I'm preaching action rather than discussions, it would hypocritical of me to not do anything so I've submitted a PR with a documentation change that I believe will make binary_to_term/1 a little clearer for anyone wondering how to use it for the first time: https://github.com/erlang/otp/pull/1181 Lukas On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: > Regarding the documentation - there is a step0 that needs to be done > *before* attacking the document improvement problem. > > The following things are needed (I my opinion) > > 1) The number of DTDs in the documentation should be reduced to ONE > there are currently 26 these are in > otp_src_/lib/erl_docgen/priv/dtd > > 2) tags that are used infrequently should be removed and the source XML > corrected. Some tags are virtually *never* used. > > 3) All XML files should validate with the new DTD > > These steps need quite a lot of work ... > > 4) The Erlang parser should be changed to exactly > reproduce the source. > Right now the parse tree of correct erlang has all the comments > and white space removed. I'd suggest attaching the comments to the > next following token (for example {atom,Line,theAtom} should become > {atom, Line, theAtom, "the preceding comments and white space"} > It should be possible to *exactly* reconstruct the input from the parse > tree. > > > > > > > > 5) We should decide how to attach "floating" comments in the source. > Does a comment *before* a function apply to the next function or not? > > 6) We need some "injection" API to inject code, meta-data, examples > and documentations into a data base. > > For example inject:code("foo.erl") should inject a load of key/value > pairs into a data base, with something like the following keys > > {text, Mod,Func,Arity} => the source code text > {spec, Mod, Func, Arity} => the spec > {doc, Mod,Func,Arity} => the documentation > {examples,Mod,Func,Arity} = [Examples] > > The entities in the database should be sufficient to reconstruct the > original text, and perform various analysis of the functions. > > I think *most* of the problems involved are due to the difficulty of > extracting information from the source files and editing this when it is > wrong. > > I'm currently trying to do parts of this. > > A "relatively simple" program should be able to (for a given function) > > - find the exact source text > - find all old versions > - find the specs and types referred to > - find the documentation > - find the test cases > > Doing so involves analysing the erlang sources the XML sources and the > test cases, and involves a deal of guess work. > > All this must be done on a moving target and should not break the > existing system. > > I suspect that the code to accurately manipulate the code and > documentation have been has been written several times in different > projects (for example > the wrangler, and the Eclipse interface) both need to manipulate the source > in various ways. > > > > > On Mon, Sep 26, 2016 at 6:41 PM, wrote: > > Joe, > > > > You've said so well what I've been trying to harp on. > > > > My most recent timesink has been trying to understand xmerl sufficiently > well to pull book data out of several different book APIs. Dave Thomas's > 2007 tutorial has been a big help, but the black holes in my understanding > still significantly impede my progress. So far I've spent maybe 10 to 15 > hours trying to scope it out. I can get much of what I need from Amazon's > APIs, but I need a redundant source. The Library of Congress API completely > eludes me; I get a little further with ISBNdb, but still not far enough. > > > > Given discussion on the documentation thread to date, it seems to me > that there are four issues at stake: > > > > 1) Content deficiencies > > 2) Formatting issues > > 3) Lack of consensus of what we, as a community, want > > 4) How we move forward toward comprehensive improvement of documentation. > > > > Lukas Larsson's most recent post makes a good point. > > > > Bruce Yinhe tells me in a private post that his group is about to hire > one person on a part-time basis to work on documentation improvements. > > > > I've lost it in the thread, but as I recall we had some promising > interest in documentation improvements from an Erricson employee. > > > > It would be great if we could begin to rally around these comments and > find some kind of convergence toward progress. > > > > My take is to break the large task down into small chunks, bring the > intelligence and resources of the community to bear on one specific issue > at a time and, and get it done. > > I think many (most) of the problems arise because what we are ultimately > doing is changing the content of a file at some place. > > Fixing a typo/bug involves > > 1- finding the appropriate file > 2 - changing the file at the appropriate place > 3 - updating the file (somehow) > 4 - generating the downstream documents that depend upon the file > > All these steps are difficult > > We can imagine a simpler way: > > Suppose a file is a sequence of paragraphs. Each paragraph > has a GUId > > In (say) HTML > >

> This is my paragarph ... >

> > If I want to update the paragraphs I just send a message > > {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" > "the new content"} > > to some server - this should be checked (manually) and then > if approved used to update everything. > > In other threads I have argued that *everything* should be in a global > database with a huge DHT tracking where things are. > > A key to "changing things" is "naming things" and "finding things" > > yes another (even simpler) alternative is to have a message > > {change,SHA,NewText} > > Meaning "change the paragraph with sha1 checksum to " > > Implementing this is easy - BUT all paragraphs with the same SHA > would be changed - which might not be what we want. > > I have (incidentally) experimented with this - tagging all paragraphs > with their SHAs and sticking the results in a database. > > > make a server that accepts messages of the form > > {change, , } > > The server finds a paragraph with sha1 checksum and changes > it to - it changes the appropriate file in a GIT archive > does all the /add/commit/push magic and the job is done. > > (I think I'll implement this for fun :-) > > > > > > > I don't have the technical chops, but I'll gladly work with you or > anyone else to address content issues on a module-by-module basis. I can > ask Micky-the_Dunce questions and, perhaps, help clarify language. It would > be great if you could help clarify intent and application issues. > > > > All the best, > > > > Lloyd > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: "Joe Armstrong" > > Sent: Monday, September 26, 2016 6:42am > > To: "Lukas Larsson" > > Cc: "Lloyd R. Prentice" , " > erlang-questions@REDACTED" > > Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal > > > > I think what I miss most are *examples* > > > > I've just been reading the edoc manual pages for a program > > called (name changed to avoid embarrassment) > > > > The functions are well documented - they types are well documented > > but I haven't a clue about which ORDER to call the functions > > > > Imagine a file system. > > > > We *document* the open, read, write, and close functions > > but we don't say you have to open the file before we read it. > > We dont say when we're done we have to close the file. > > > > We don't say this because it is *obvious* > > > > But for the module glonk, which exports, zizzle, taddle, glonk and plonk > > it is NOT obvious. Yes sure you all know you have to call glonk 3 times > > before calling plonk - but I don't know. > > > > Thats why we need examples. > > > > Often I search for a tutorial and find a ten line blog posting that > > actually shows me how to use a library - this gets me started. > > > > very short unit tests - placed inline are *very* useful > > > > for example: > > > > "321" = lists:reverse("123") > > > > The unit test *are* the examples - what we don't have is software that > > parses the code, parses the documentation, parses the unit test > > and munges all together into a form that is convenient to read. > > > > I'm actually trying to write something like this now - hence my wails > > of anguish over css. > > > > Wish me luck > > > > /Joe > > > > > > > > > > > > > > > > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson > wrote: > >> Hello, > >> > >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice < > lloyd@REDACTED> > >> wrote: > >>> > >>> Hello, > >>> > >>> To date, this thread has generated quite a few worthwhile insights and > >>> ideas. My fear is that they will be deep-sixed into the archive. On the > >>> other hand, major revision is a daunting task and unlikely to happen. > >>> > >>> But maybe we can focus on specific issues and make iterative headway. > >>> > >>> Fewer than half of the functions in the lists library, for instance, > have > >>> code examples. Suppose over the span of one week we were collectively > focus > >>> on generating at least two code examples for each function in one > library. > >>> > >>> At the end of the week we could organize the submissions and vote on > best > >>> candidates for inclusion in the docs. That done, we can pick another > module. > >>> > >>> Thus, with not much effort from any one individual, a small posse of > >>> volunteer Erlang wizards could make short work of deficiencies in the > docs. > >>> > >>> Anyway, it's an idea. > >>> > >>> All the best, > >>> > >>> LRP > >>> > >> > >> I think that it is great to see everyone talking about wanting to > improve > >> the documentation. The contributions to the Erlang/OTP project that I > value > >> that most are documentation changes that make the intention clearer, or > >> explains some corner case somewhere which the docs did not initially > >> mention. > >> > >> Unfortunately, once one has figured out how a function works there > seems to > >> be very little incentive to make the docs clearer. I would estimate that > >> about every 20th pull request we get is a documentation fix, and more > than > >> half of those are fixes of speling misstakes (which are great!). > >> > >> I've just come back from about two weeks of vacation and this > discussion has > >> resulted in roughly 0 pull requests for changes in the documentation. > Would > >> it be possible to steer this discussion into doing something instead of > >> talking about doing something? Yes the technology/layout is not > perfect, but > >> as Lo?c said, it is the content that matters the most. > >> > >> Lukas > >> // my own oppinions > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > > From erlang.org@REDACTED Tue Sep 27 01:55:28 2016 From: erlang.org@REDACTED (Stanislaw Klekot) Date: Tue, 27 Sep 2016 01:55:28 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <21d16e06-6b49-ba73-cb6f-517e16b131c5@cs.otago.ac.nz> References: <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <9b90c91a-2cda-3b24-9427-061b5ceca21d@informatik.haw-hamburg.de> <21d16e06-6b49-ba73-cb6f-517e16b131c5@cs.otago.ac.nz> Message-ID: <20160926235528.GA20096@jarowit.net> On Tue, Sep 27, 2016 at 10:49:13AM +1300, Richard A. O'Keefe wrote: > I was thinking of a number of fairly popular open source projects > where there was a sketchy tutorial and then a Doxygen puke (with > many of the functions uncommented, just automatic headers) *instead* > of documentation. > > Actually, if you look at source code, there are often cues to be had > from the words inside the functions. > > I guess it depends on what you mean by "published Doxygen". > I was meaning "so-called documentation made available to people outside > the project generated using Doxygen." Just running a Doxygen or JavaDoc or EDoc on an unprepared source code is surely far from enough. I don't consider just listing of functions and types of their parameters a documentation. Such listing would seem to be as raw and somehow... naked. I don't leave my code in such state. On the other hand, all of these tools give a predictable structure to generated documents, which often corresponds well to how I typically consume the reference manual. I already know how to navigate them, which is a big plus. What I miss in EDoc in particular is a good way to add pages that don't refer to any particular module, like examples or walkthrough. I worked out a template of putting dummy, empty modules in ./examples/*.erl and adding ./examples/ to source path for EDoc, which works well, but it's an abuse of the application and I would prefer to have a dedicated way. What I liked the best is Sphinx (a tool formerly dedicated to Python, now much more universal; already mentioned in this thread). It allows to write documentation with no autogenerated content, yet there is a way to embed parts extracted from source code, so it's best of both worlds, I think. Unfortunately one needs to think documentation's structure beforehand, so it's a larger effort to start than just running EDoc/JavaDoc (but totally worth it). -- Stanislaw Klekot From ok@REDACTED Tue Sep 27 04:38:48 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 27 Sep 2016 15:38:48 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <62A45CDF-5FED-4AD6-AA5B-CE82797C4813@laposte.net> References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <62A45CDF-5FED-4AD6-AA5B-CE82797C4813@laposte.net> Message-ID: On 27/09/16 7:01 AM, Marco Molteni wrote: > my suggestion for the documentation format is asciidoc. I think the kind of "format" that people were concerned about is *presentation* format. From the point of view of someone *reading* documentation, it's really not very interesting how the documentation was *written*. The issues that matter most are - is the text clear and good enough that its errors in spelling/grammar/punctuation aren't distracting? - is the information correct? - is the information adequate? - are there appropriate navigation aids to help me find related content easily and obviously? - is the content up to date? After that we care about - is all the information accessible through audio? - have contrast-reducing things like coloured text been avoided in everything the user needs to read? - does the typography direct the reader to important things or is it distracting? - does the presentation form need a manual or is it obvious to anyone familiar with (reading paper / using a PDF viewer / using a web browser)? - can the documentation be plugged into an IDE (including the UNIX command line as an IDE)? As someone who would like to offer the occasional correction/extension to the Erlang documentation, then I care about the markup language. As for asciidoc, let's just say that when I installed it, I had to fight my way past dead links, install Yet Another Fine Build program, install yet another program, fight my way past dead links in that, and then when I was finally able to run 'a2x' on something, it claimed that xmllint didn't like the output except that xmllint *did* like the output, and at that point I gave up. But not before I had tried installing asciidoctor, which didn't work (dead gem link, I think). And all of that was today. (I am also heartily sick of programs that assume that if you are using a Mac you have full root access and can use things like Fink and Brew and install things in places other than your own ~ tree. It just isn't so.) I have *roff (both Legacy and GNU), (La)TeX, Lout, an assortment of tools for processing SGML and XML, FOP, Erlang, &c. I also have multiple Markdown tools (because there are so many Markdowns) which I only use to process other people's stuff. I am so tired of NIH. So very very tired of it. > And it is the only format I ever found that allowed me to avoid LaTeX I for one have no particular desire to avoid LaTeX. It doesn't constrict the range of the thinkable the way that Markdown does. From ok@REDACTED Tue Sep 27 05:23:29 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 27 Sep 2016 16:23:29 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> <98209ec5-295d-6e34-4425-4c49504a17d2@ninenines.eu> Message-ID: <732a5f7f-0261-14e2-9479-6fb4b59feadc@cs.otago.ac.nz> On 27/09/16 10:56 AM, Richard A. O'Keefe wrote: > > There is a document formatter which has, or could have, a defined parse > tree, and that's Lout. https://en.wikipedia.org/wiki/Lout_(software) > Lout picked up the idea of declarative documents from SCRIBE. Did I mention that the extension language for Lout is functional? PS: I can't be the only person here to have heard of Lout. Anyone have an Erlang (or Prolog or SML) file for prg2lout? From erlang@REDACTED Tue Sep 27 08:26:52 2016 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 27 Sep 2016 08:26:52 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: On Mon, Sep 26, 2016 at 10:51 PM, Lukas Larsson wrote: > Hello Joe, > > What you are talking about is about lowering the cost of entry when doing > documentation updates. This is a great effort and one which we should really > pursue, but as you say it is a lot of work. Is there really a *need* for > that to be in place first? Can't there be lots of smaller parallel efforts > (we as Erlang programmers should be familiar with the concept) that improve > the content at the same time? > > Since I'm preaching action rather than discussions, it would hypocritical of > me to not do anything so I've submitted a PR with a documentation change > that I believe will make binary_to_term/1 a little clearer for anyone > wondering how to use it for the first time: > https://github.com/erlang/otp/pull/1181 Thank you Lukas. This patch made my head explode. How can an example of binary_to_term NOT mention term_to_binary? When I lecture I say that that the PAIR of functions term_to_binary and binary_to_term are FANTASTIC - and I hang my head in shame if having read one of my books this fact was not made abundantly clear. NOT ALL FUNCTIONS ARE EQUALLY IMPORTANT The Erlang manual page is *gigantic* I for one, certainly don't know all the functions in the Erlang manual page - I also only use a handful of functions in file, dict and lists It occurs to me that I probably only use 5% of the functions in file.erl 8% of the functions in dict.erl and so on. I don't know the numbers here, so I'm guessing. Since I can manage perfectly well knowing only 5% of the functions in file, then I'd like to ask - do we need all the other functions? Answer: Yes - on rare occasions I need a specific functionality, so I have search the manual page and read the text very carefully - do beginners know which functions in (say file) are what I consider to be the important ones? Answer: No - how could they So here's an idea .. we (or I in this case) write a 'best of' document The best of should have: - the *best* modules (which modules do I use most) - the *best functions* (which functions (per module) do I use most) I think I "know" that answers without analysis. So, for example, in dict.erl I'd hazard I guess that I use new/1, store/3, find/2, from_list/1, to_list/2. For me these functions are in my 'working set' of functions. ie the functions that I use a lot and are in my memory. It seems to me that it might be beneficial to make some special 'best of' documentation that only documents the essential core functions in the libraries. I'd also like to compare my 'best of' lists with other programmers on this list. What are Richard and Lukas favorite functions? I can easily write a program to statically analyse my code to pull out these figures. I think it would be a good idea if instead of throwing 10MBytes of documentation at beginners we should aim to tell them what the essential set of modules is, and what the essential functions are in those modules and how they should be used. As for advanced users - the documentation we have is all we have - and gradual improvement is needed. Cheers /Joe > > Lukas > > On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: >> >> Regarding the documentation - there is a step0 that needs to be done >> *before* attacking the document improvement problem. >> >> The following things are needed (I my opinion) >> >> 1) The number of DTDs in the documentation should be reduced to ONE >> there are currently 26 these are in >> otp_src_/lib/erl_docgen/priv/dtd >> >> 2) tags that are used infrequently should be removed and the source XML >> corrected. Some tags are virtually *never* used. >> >> 3) All XML files should validate with the new DTD >> >> These steps need quite a lot of work ... >> >> 4) The Erlang parser should be changed to exactly >> reproduce the source. >> Right now the parse tree of correct erlang has all the comments >> and white space removed. I'd suggest attaching the comments to the >> next following token (for example {atom,Line,theAtom} should become >> {atom, Line, theAtom, "the preceding comments and white space"} >> It should be possible to *exactly* reconstruct the input from the parse >> tree. >> >> >> >> >> >> >> >> 5) We should decide how to attach "floating" comments in the source. >> Does a comment *before* a function apply to the next function or not? >> >> 6) We need some "injection" API to inject code, meta-data, examples >> and documentations into a data base. >> >> For example inject:code("foo.erl") should inject a load of key/value >> pairs into a data base, with something like the following keys >> >> {text, Mod,Func,Arity} => the source code text >> {spec, Mod, Func, Arity} => the spec >> {doc, Mod,Func,Arity} => the documentation >> {examples,Mod,Func,Arity} = [Examples] >> >> The entities in the database should be sufficient to reconstruct the >> original text, and perform various analysis of the functions. >> >> I think *most* of the problems involved are due to the difficulty of >> extracting information from the source files and editing this when it is >> wrong. >> >> I'm currently trying to do parts of this. >> >> A "relatively simple" program should be able to (for a given function) >> >> - find the exact source text >> - find all old versions >> - find the specs and types referred to >> - find the documentation >> - find the test cases >> >> Doing so involves analysing the erlang sources the XML sources and the >> test cases, and involves a deal of guess work. >> >> All this must be done on a moving target and should not break the >> existing system. >> >> I suspect that the code to accurately manipulate the code and >> documentation have been has been written several times in different >> projects (for example >> the wrangler, and the Eclipse interface) both need to manipulate the >> source >> in various ways. >> >> >> >> >> On Mon, Sep 26, 2016 at 6:41 PM, wrote: >> > Joe, >> > >> > You've said so well what I've been trying to harp on. >> > >> > My most recent timesink has been trying to understand xmerl sufficiently >> > well to pull book data out of several different book APIs. Dave Thomas's >> > 2007 tutorial has been a big help, but the black holes in my understanding >> > still significantly impede my progress. So far I've spent maybe 10 to 15 >> > hours trying to scope it out. I can get much of what I need from Amazon's >> > APIs, but I need a redundant source. The Library of Congress API completely >> > eludes me; I get a little further with ISBNdb, but still not far enough. >> > >> > Given discussion on the documentation thread to date, it seems to me >> > that there are four issues at stake: >> > >> > 1) Content deficiencies >> > 2) Formatting issues >> > 3) Lack of consensus of what we, as a community, want >> > 4) How we move forward toward comprehensive improvement of >> > documentation. >> > >> > Lukas Larsson's most recent post makes a good point. >> > >> > Bruce Yinhe tells me in a private post that his group is about to hire >> > one person on a part-time basis to work on documentation improvements. >> > >> > I've lost it in the thread, but as I recall we had some promising >> > interest in documentation improvements from an Erricson employee. >> > >> > It would be great if we could begin to rally around these comments and >> > find some kind of convergence toward progress. >> > >> > My take is to break the large task down into small chunks, bring the >> > intelligence and resources of the community to bear on one specific issue at >> > a time and, and get it done. >> >> I think many (most) of the problems arise because what we are ultimately >> doing is changing the content of a file at some place. >> >> Fixing a typo/bug involves >> >> 1- finding the appropriate file >> 2 - changing the file at the appropriate place >> 3 - updating the file (somehow) >> 4 - generating the downstream documents that depend upon the file >> >> All these steps are difficult >> >> We can imagine a simpler way: >> >> Suppose a file is a sequence of paragraphs. Each paragraph >> has a GUId >> >> In (say) HTML >> >>

>> This is my paragarph ... >>

>> >> If I want to update the paragraphs I just send a message >> >> {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" >> "the new content"} >> >> to some server - this should be checked (manually) and then >> if approved used to update everything. >> >> In other threads I have argued that *everything* should be in a global >> database with a huge DHT tracking where things are. >> >> A key to "changing things" is "naming things" and "finding things" >> >> yes another (even simpler) alternative is to have a message >> >> {change,SHA,NewText} >> >> Meaning "change the paragraph with sha1 checksum to " >> >> Implementing this is easy - BUT all paragraphs with the same SHA >> would be changed - which might not be what we want. >> >> I have (incidentally) experimented with this - tagging all paragraphs >> with their SHAs and sticking the results in a database. >> >> >> make a server that accepts messages of the form >> >> {change, , } >> >> The server finds a paragraph with sha1 checksum and changes >> it to - it changes the appropriate file in a GIT archive >> does all the /add/commit/push magic and the job is done. >> >> (I think I'll implement this for fun :-) >> >> >> >> > >> > I don't have the technical chops, but I'll gladly work with you or >> > anyone else to address content issues on a module-by-module basis. I can ask >> > Micky-the_Dunce questions and, perhaps, help clarify language. It would be >> > great if you could help clarify intent and application issues. >> > >> > All the best, >> > >> > Lloyd >> > >> > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: "Joe Armstrong" >> > Sent: Monday, September 26, 2016 6:42am >> > To: "Lukas Larsson" >> > Cc: "Lloyd R. Prentice" , >> > "erlang-questions@REDACTED" >> > Subject: Re: [erlang-questions] Erlang documentation -- a modest >> > proposal >> > >> > I think what I miss most are *examples* >> > >> > I've just been reading the edoc manual pages for a program >> > called (name changed to avoid embarrassment) >> > >> > The functions are well documented - they types are well documented >> > but I haven't a clue about which ORDER to call the functions >> > >> > Imagine a file system. >> > >> > We *document* the open, read, write, and close functions >> > but we don't say you have to open the file before we read it. >> > We dont say when we're done we have to close the file. >> > >> > We don't say this because it is *obvious* >> > >> > But for the module glonk, which exports, zizzle, taddle, glonk and plonk >> > it is NOT obvious. Yes sure you all know you have to call glonk 3 times >> > before calling plonk - but I don't know. >> > >> > Thats why we need examples. >> > >> > Often I search for a tutorial and find a ten line blog posting that >> > actually shows me how to use a library - this gets me started. >> > >> > very short unit tests - placed inline are *very* useful >> > >> > for example: >> > >> > "321" = lists:reverse("123") >> > >> > The unit test *are* the examples - what we don't have is software that >> > parses the code, parses the documentation, parses the unit test >> > and munges all together into a form that is convenient to read. >> > >> > I'm actually trying to write something like this now - hence my wails >> > of anguish over css. >> > >> > Wish me luck >> > >> > /Joe >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson >> > wrote: >> >> Hello, >> >> >> >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice >> >> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> To date, this thread has generated quite a few worthwhile insights and >> >>> ideas. My fear is that they will be deep-sixed into the archive. On >> >>> the >> >>> other hand, major revision is a daunting task and unlikely to happen. >> >>> >> >>> But maybe we can focus on specific issues and make iterative headway. >> >>> >> >>> Fewer than half of the functions in the lists library, for instance, >> >>> have >> >>> code examples. Suppose over the span of one week we were collectively >> >>> focus >> >>> on generating at least two code examples for each function in one >> >>> library. >> >>> >> >>> At the end of the week we could organize the submissions and vote on >> >>> best >> >>> candidates for inclusion in the docs. That done, we can pick another >> >>> module. >> >>> >> >>> Thus, with not much effort from any one individual, a small posse of >> >>> volunteer Erlang wizards could make short work of deficiencies in the >> >>> docs. >> >>> >> >>> Anyway, it's an idea. >> >>> >> >>> All the best, >> >>> >> >>> LRP >> >>> >> >> >> >> I think that it is great to see everyone talking about wanting to >> >> improve >> >> the documentation. The contributions to the Erlang/OTP project that I >> >> value >> >> that most are documentation changes that make the intention clearer, or >> >> explains some corner case somewhere which the docs did not initially >> >> mention. >> >> >> >> Unfortunately, once one has figured out how a function works there >> >> seems to >> >> be very little incentive to make the docs clearer. I would estimate >> >> that >> >> about every 20th pull request we get is a documentation fix, and more >> >> than >> >> half of those are fixes of speling misstakes (which are great!). >> >> >> >> I've just come back from about two weeks of vacation and this >> >> discussion has >> >> resulted in roughly 0 pull requests for changes in the documentation. >> >> Would >> >> it be possible to steer this discussion into doing something instead of >> >> talking about doing something? Yes the technology/layout is not >> >> perfect, but >> >> as Lo?c said, it is the content that matters the most. >> >> >> >> Lukas >> >> // my own oppinions >> >> >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > >> > > > From erlang@REDACTED Tue Sep 27 08:29:41 2016 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 27 Sep 2016 08:29:41 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <732a5f7f-0261-14e2-9479-6fb4b59feadc@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> <98209ec5-295d-6e34-4425-4c49504a17d2@ninenines.eu> <732a5f7f-0261-14e2-9479-6fb4b59feadc@cs.otago.ac.nz> Message-ID: On Tue, Sep 27, 2016 at 5:23 AM, Richard A. O'Keefe wrote: > > On 27/09/16 10:56 AM, Richard A. O'Keefe wrote: >> >> >> There is a document formatter which has, or could have, a defined parse >> tree, and that's Lout. https://en.wikipedia.org/wiki/Lout_(software) >> Lout picked up the idea of declarative documents from SCRIBE. > > > Did I mention that the extension language for Lout is functional? > > PS: I can't be the only person here to have heard of Lout. > Anyone have an Erlang (or Prolog or SML) file for prg2lout? No Richard, I've heard of Lout, I've even used it a long time ago. It's kind of slipped off my radar, I wonder if it's still supported, or was it so well written that it still works? /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Tue Sep 27 08:32:00 2016 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 27 Sep 2016 08:32:00 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: On Mon, Sep 26, 2016 at 10:49 PM, Vlad Dumitrescu wrote: > Hi Joe, > > On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: >> >> 4) The Erlang parser should be changed to exactly >> reproduce the source. >> Right now the parse tree of correct erlang has all the comments >> and white space removed. I'd suggest attaching the comments to the >> next following token (for example {atom,Line,theAtom} should become >> {atom, Line, theAtom, "the preceding comments and white space"} >> It should be possible to *exactly* reconstruct the input from the parse >> tree. >> >> > > > This is what I set out to implement with 'sourcer' > (https://github.com/erlang/sourcer). I am actually aiming even higher: keep > track of macros and -ifdefs and the possibly different structure of a module > when considering them. Also, I want to be able to parse code that is in the > process of being edited (only possible if knowing the latest parseable state > of the file). On the bright side, this parser need not replace erl_parse. > The compiler and most tools don't need all this extra detail. It would be > good to be able to not implement _everything_ from scratch, but I couldn't > find a way to do all this than with a hand-written parser. Ideas, feedback, > suggestions, improvements and rotten tomatoes are welcome. Great - I shall take a look. /Joe > > regards, > Vlad > From erlang@REDACTED Tue Sep 27 08:51:08 2016 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 27 Sep 2016 08:51:08 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: Best of lists Can we run some quick polls? I'd like to ask as many users as possible - the best modules to learn - the best functions (per module) We could set up a poll and vote for our favorite modules I'd also like to ask the experience level of the responder Then we could concentrate our documentation efforts on the most popular functions (or is there a better way to discover the best-of list?) Is there a good web thingummyjig for this? /Joe On Tue, Sep 27, 2016 at 8:26 AM, Joe Armstrong wrote: > On Mon, Sep 26, 2016 at 10:51 PM, Lukas Larsson wrote: >> Hello Joe, >> >> What you are talking about is about lowering the cost of entry when doing >> documentation updates. This is a great effort and one which we should really >> pursue, but as you say it is a lot of work. Is there really a *need* for >> that to be in place first? Can't there be lots of smaller parallel efforts >> (we as Erlang programmers should be familiar with the concept) that improve >> the content at the same time? >> >> Since I'm preaching action rather than discussions, it would hypocritical of >> me to not do anything so I've submitted a PR with a documentation change >> that I believe will make binary_to_term/1 a little clearer for anyone >> wondering how to use it for the first time: >> https://github.com/erlang/otp/pull/1181 > > Thank you Lukas. > > This patch made my head explode. > > How can an example of binary_to_term NOT mention term_to_binary? > > When I lecture I say that that the PAIR of functions term_to_binary > and binary_to_term are FANTASTIC - and I hang my head in shame > if having read one of my books this fact was not made abundantly clear. > > NOT ALL FUNCTIONS ARE EQUALLY IMPORTANT > > The Erlang manual page is *gigantic* I for one, certainly don't know all > the functions in the Erlang manual page - I also only use a handful of > functions in file, dict and lists > > It occurs to me that I probably only use 5% of the functions in file.erl > 8% of the functions in dict.erl and so on. I don't know the numbers here, > so I'm guessing. > > Since I can manage perfectly well > knowing only 5% of the functions in file, then I'd like to ask > > - do we need all the other functions? > > Answer: Yes - on rare occasions I need a specific functionality, so I have > search the manual page and read the text very carefully > > - do beginners know which functions in (say file) are what I consider > to be the important ones? > > Answer: No - how could they > > So here's an idea .. we (or I in this case) write a 'best of' document > The best of should have: > > - the *best* modules (which modules do I use most) > - the *best functions* (which functions (per module) do I use most) > > I think I "know" that answers without analysis. > > So, for example, in dict.erl I'd hazard I guess that I use new/1, > store/3, find/2, from_list/1, to_list/2. > > For me these functions are in my 'working set' of functions. ie the > functions that I use a lot and are in my memory. > > It seems to me that it might be beneficial to make some special > 'best of' documentation that only documents the essential core functions in > the libraries. > > I'd also like to compare my 'best of' lists with other programmers on this list. > What are Richard and Lukas favorite functions? > > I can easily write a program to statically analyse my code to pull out > these figures. > > I think it would be a good idea if instead of throwing 10MBytes of > documentation at beginners we should aim to tell them what the > essential > set of modules is, and what the essential functions are in those modules > and how they should be used. > > As for advanced users - the documentation we have is all we have - and > gradual improvement is needed. > > Cheers > > /Joe > > > > > > > > > > >> >> Lukas >> >> On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: >>> >>> Regarding the documentation - there is a step0 that needs to be done >>> *before* attacking the document improvement problem. >>> >>> The following things are needed (I my opinion) >>> >>> 1) The number of DTDs in the documentation should be reduced to ONE >>> there are currently 26 these are in >>> otp_src_/lib/erl_docgen/priv/dtd >>> >>> 2) tags that are used infrequently should be removed and the source XML >>> corrected. Some tags are virtually *never* used. >>> >>> 3) All XML files should validate with the new DTD >>> >>> These steps need quite a lot of work ... >>> >>> 4) The Erlang parser should be changed to exactly >>> reproduce the source. >>> Right now the parse tree of correct erlang has all the comments >>> and white space removed. I'd suggest attaching the comments to the >>> next following token (for example {atom,Line,theAtom} should become >>> {atom, Line, theAtom, "the preceding comments and white space"} >>> It should be possible to *exactly* reconstruct the input from the parse >>> tree. >>> >>> >>> >>> >>> >>> >>> >>> 5) We should decide how to attach "floating" comments in the source. >>> Does a comment *before* a function apply to the next function or not? >>> >>> 6) We need some "injection" API to inject code, meta-data, examples >>> and documentations into a data base. >>> >>> For example inject:code("foo.erl") should inject a load of key/value >>> pairs into a data base, with something like the following keys >>> >>> {text, Mod,Func,Arity} => the source code text >>> {spec, Mod, Func, Arity} => the spec >>> {doc, Mod,Func,Arity} => the documentation >>> {examples,Mod,Func,Arity} = [Examples] >>> >>> The entities in the database should be sufficient to reconstruct the >>> original text, and perform various analysis of the functions. >>> >>> I think *most* of the problems involved are due to the difficulty of >>> extracting information from the source files and editing this when it is >>> wrong. >>> >>> I'm currently trying to do parts of this. >>> >>> A "relatively simple" program should be able to (for a given function) >>> >>> - find the exact source text >>> - find all old versions >>> - find the specs and types referred to >>> - find the documentation >>> - find the test cases >>> >>> Doing so involves analysing the erlang sources the XML sources and the >>> test cases, and involves a deal of guess work. >>> >>> All this must be done on a moving target and should not break the >>> existing system. >>> >>> I suspect that the code to accurately manipulate the code and >>> documentation have been has been written several times in different >>> projects (for example >>> the wrangler, and the Eclipse interface) both need to manipulate the >>> source >>> in various ways. >>> >>> >>> >>> >>> On Mon, Sep 26, 2016 at 6:41 PM, wrote: >>> > Joe, >>> > >>> > You've said so well what I've been trying to harp on. >>> > >>> > My most recent timesink has been trying to understand xmerl sufficiently >>> > well to pull book data out of several different book APIs. Dave Thomas's >>> > 2007 tutorial has been a big help, but the black holes in my understanding >>> > still significantly impede my progress. So far I've spent maybe 10 to 15 >>> > hours trying to scope it out. I can get much of what I need from Amazon's >>> > APIs, but I need a redundant source. The Library of Congress API completely >>> > eludes me; I get a little further with ISBNdb, but still not far enough. >>> > >>> > Given discussion on the documentation thread to date, it seems to me >>> > that there are four issues at stake: >>> > >>> > 1) Content deficiencies >>> > 2) Formatting issues >>> > 3) Lack of consensus of what we, as a community, want >>> > 4) How we move forward toward comprehensive improvement of >>> > documentation. >>> > >>> > Lukas Larsson's most recent post makes a good point. >>> > >>> > Bruce Yinhe tells me in a private post that his group is about to hire >>> > one person on a part-time basis to work on documentation improvements. >>> > >>> > I've lost it in the thread, but as I recall we had some promising >>> > interest in documentation improvements from an Erricson employee. >>> > >>> > It would be great if we could begin to rally around these comments and >>> > find some kind of convergence toward progress. >>> > >>> > My take is to break the large task down into small chunks, bring the >>> > intelligence and resources of the community to bear on one specific issue at >>> > a time and, and get it done. >>> >>> I think many (most) of the problems arise because what we are ultimately >>> doing is changing the content of a file at some place. >>> >>> Fixing a typo/bug involves >>> >>> 1- finding the appropriate file >>> 2 - changing the file at the appropriate place >>> 3 - updating the file (somehow) >>> 4 - generating the downstream documents that depend upon the file >>> >>> All these steps are difficult >>> >>> We can imagine a simpler way: >>> >>> Suppose a file is a sequence of paragraphs. Each paragraph >>> has a GUId >>> >>> In (say) HTML >>> >>>

>>> This is my paragarph ... >>>

>>> >>> If I want to update the paragraphs I just send a message >>> >>> {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" >>> "the new content"} >>> >>> to some server - this should be checked (manually) and then >>> if approved used to update everything. >>> >>> In other threads I have argued that *everything* should be in a global >>> database with a huge DHT tracking where things are. >>> >>> A key to "changing things" is "naming things" and "finding things" >>> >>> yes another (even simpler) alternative is to have a message >>> >>> {change,SHA,NewText} >>> >>> Meaning "change the paragraph with sha1 checksum to " >>> >>> Implementing this is easy - BUT all paragraphs with the same SHA >>> would be changed - which might not be what we want. >>> >>> I have (incidentally) experimented with this - tagging all paragraphs >>> with their SHAs and sticking the results in a database. >>> >>> >>> make a server that accepts messages of the form >>> >>> {change, , } >>> >>> The server finds a paragraph with sha1 checksum and changes >>> it to - it changes the appropriate file in a GIT archive >>> does all the /add/commit/push magic and the job is done. >>> >>> (I think I'll implement this for fun :-) >>> >>> >>> >>> > >>> > I don't have the technical chops, but I'll gladly work with you or >>> > anyone else to address content issues on a module-by-module basis. I can ask >>> > Micky-the_Dunce questions and, perhaps, help clarify language. It would be >>> > great if you could help clarify intent and application issues. >>> > >>> > All the best, >>> > >>> > Lloyd >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: "Joe Armstrong" >>> > Sent: Monday, September 26, 2016 6:42am >>> > To: "Lukas Larsson" >>> > Cc: "Lloyd R. Prentice" , >>> > "erlang-questions@REDACTED" >>> > Subject: Re: [erlang-questions] Erlang documentation -- a modest >>> > proposal >>> > >>> > I think what I miss most are *examples* >>> > >>> > I've just been reading the edoc manual pages for a program >>> > called (name changed to avoid embarrassment) >>> > >>> > The functions are well documented - they types are well documented >>> > but I haven't a clue about which ORDER to call the functions >>> > >>> > Imagine a file system. >>> > >>> > We *document* the open, read, write, and close functions >>> > but we don't say you have to open the file before we read it. >>> > We dont say when we're done we have to close the file. >>> > >>> > We don't say this because it is *obvious* >>> > >>> > But for the module glonk, which exports, zizzle, taddle, glonk and plonk >>> > it is NOT obvious. Yes sure you all know you have to call glonk 3 times >>> > before calling plonk - but I don't know. >>> > >>> > Thats why we need examples. >>> > >>> > Often I search for a tutorial and find a ten line blog posting that >>> > actually shows me how to use a library - this gets me started. >>> > >>> > very short unit tests - placed inline are *very* useful >>> > >>> > for example: >>> > >>> > "321" = lists:reverse("123") >>> > >>> > The unit test *are* the examples - what we don't have is software that >>> > parses the code, parses the documentation, parses the unit test >>> > and munges all together into a form that is convenient to read. >>> > >>> > I'm actually trying to write something like this now - hence my wails >>> > of anguish over css. >>> > >>> > Wish me luck >>> > >>> > /Joe >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson >>> > wrote: >>> >> Hello, >>> >> >>> >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice >>> >> >>> >> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> To date, this thread has generated quite a few worthwhile insights and >>> >>> ideas. My fear is that they will be deep-sixed into the archive. On >>> >>> the >>> >>> other hand, major revision is a daunting task and unlikely to happen. >>> >>> >>> >>> But maybe we can focus on specific issues and make iterative headway. >>> >>> >>> >>> Fewer than half of the functions in the lists library, for instance, >>> >>> have >>> >>> code examples. Suppose over the span of one week we were collectively >>> >>> focus >>> >>> on generating at least two code examples for each function in one >>> >>> library. >>> >>> >>> >>> At the end of the week we could organize the submissions and vote on >>> >>> best >>> >>> candidates for inclusion in the docs. That done, we can pick another >>> >>> module. >>> >>> >>> >>> Thus, with not much effort from any one individual, a small posse of >>> >>> volunteer Erlang wizards could make short work of deficiencies in the >>> >>> docs. >>> >>> >>> >>> Anyway, it's an idea. >>> >>> >>> >>> All the best, >>> >>> >>> >>> LRP >>> >>> >>> >> >>> >> I think that it is great to see everyone talking about wanting to >>> >> improve >>> >> the documentation. The contributions to the Erlang/OTP project that I >>> >> value >>> >> that most are documentation changes that make the intention clearer, or >>> >> explains some corner case somewhere which the docs did not initially >>> >> mention. >>> >> >>> >> Unfortunately, once one has figured out how a function works there >>> >> seems to >>> >> be very little incentive to make the docs clearer. I would estimate >>> >> that >>> >> about every 20th pull request we get is a documentation fix, and more >>> >> than >>> >> half of those are fixes of speling misstakes (which are great!). >>> >> >>> >> I've just come back from about two weeks of vacation and this >>> >> discussion has >>> >> resulted in roughly 0 pull requests for changes in the documentation. >>> >> Would >>> >> it be possible to steer this discussion into doing something instead of >>> >> talking about doing something? Yes the technology/layout is not >>> >> perfect, but >>> >> as Lo?c said, it is the content that matters the most. >>> >> >>> >> Lukas >>> >> // my own oppinions >>> >> >>> >> _______________________________________________ >>> >> erlang-questions mailing list >>> >> erlang-questions@REDACTED >>> >> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >>> > >>> > >> >> From bengt.kleberg@REDACTED Tue Sep 27 08:59:58 2016 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 27 Sep 2016 08:59:58 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: Greetings, My manager uses mentimeter.com to poll us (the unit) during unit meetings. bengt On 09/27/2016 08:51 AM, Joe Armstrong wrote: > Best of lists > > Can we run some quick polls? > > I'd like to ask as many users as possible > > - the best modules to learn > - the best functions (per module) > > We could set up a poll and vote for our favorite modules > > I'd also like to ask the experience level of the responder > > Then we could concentrate our documentation efforts on the most > popular functions (or is there a better way to discover the best-of > list?) > > Is there a good web thingummyjig for this? > > /Joe > > On Tue, Sep 27, 2016 at 8:26 AM, Joe Armstrong wrote: >> On Mon, Sep 26, 2016 at 10:51 PM, Lukas Larsson wrote: >>> Hello Joe, >>> >>> What you are talking about is about lowering the cost of entry when doing >>> documentation updates. This is a great effort and one which we should really >>> pursue, but as you say it is a lot of work. Is there really a *need* for >>> that to be in place first? Can't there be lots of smaller parallel efforts >>> (we as Erlang programmers should be familiar with the concept) that improve >>> the content at the same time? >>> >>> Since I'm preaching action rather than discussions, it would hypocritical of >>> me to not do anything so I've submitted a PR with a documentation change >>> that I believe will make binary_to_term/1 a little clearer for anyone >>> wondering how to use it for the first time: >>> https://github.com/erlang/otp/pull/1181 >> Thank you Lukas. >> >> This patch made my head explode. >> >> How can an example of binary_to_term NOT mention term_to_binary? >> >> When I lecture I say that that the PAIR of functions term_to_binary >> and binary_to_term are FANTASTIC - and I hang my head in shame >> if having read one of my books this fact was not made abundantly clear. >> >> NOT ALL FUNCTIONS ARE EQUALLY IMPORTANT >> >> The Erlang manual page is *gigantic* I for one, certainly don't know all >> the functions in the Erlang manual page - I also only use a handful of >> functions in file, dict and lists >> >> It occurs to me that I probably only use 5% of the functions in file.erl >> 8% of the functions in dict.erl and so on. I don't know the numbers here, >> so I'm guessing. >> >> Since I can manage perfectly well >> knowing only 5% of the functions in file, then I'd like to ask >> >> - do we need all the other functions? >> >> Answer: Yes - on rare occasions I need a specific functionality, so I have >> search the manual page and read the text very carefully >> >> - do beginners know which functions in (say file) are what I consider >> to be the important ones? >> >> Answer: No - how could they >> >> So here's an idea .. we (or I in this case) write a 'best of' document >> The best of should have: >> >> - the *best* modules (which modules do I use most) >> - the *best functions* (which functions (per module) do I use most) >> >> I think I "know" that answers without analysis. >> >> So, for example, in dict.erl I'd hazard I guess that I use new/1, >> store/3, find/2, from_list/1, to_list/2. >> >> For me these functions are in my 'working set' of functions. ie the >> functions that I use a lot and are in my memory. >> >> It seems to me that it might be beneficial to make some special >> 'best of' documentation that only documents the essential core functions in >> the libraries. >> >> I'd also like to compare my 'best of' lists with other programmers on this list. >> What are Richard and Lukas favorite functions? >> >> I can easily write a program to statically analyse my code to pull out >> these figures. >> >> I think it would be a good idea if instead of throwing 10MBytes of >> documentation at beginners we should aim to tell them what the >> essential >> set of modules is, and what the essential functions are in those modules >> and how they should be used. >> >> As for advanced users - the documentation we have is all we have - and >> gradual improvement is needed. >> >> Cheers >> >> /Joe >> >> >> >> >> >> >> >> >> >> >>> Lukas >>> >>> On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: >>>> Regarding the documentation - there is a step0 that needs to be done >>>> *before* attacking the document improvement problem. >>>> >>>> The following things are needed (I my opinion) >>>> >>>> 1) The number of DTDs in the documentation should be reduced to ONE >>>> there are currently 26 these are in >>>> otp_src_/lib/erl_docgen/priv/dtd >>>> >>>> 2) tags that are used infrequently should be removed and the source XML >>>> corrected. Some tags are virtually *never* used. >>>> >>>> 3) All XML files should validate with the new DTD >>>> >>>> These steps need quite a lot of work ... >>>> >>>> 4) The Erlang parser should be changed to exactly >>>> reproduce the source. >>>> Right now the parse tree of correct erlang has all the comments >>>> and white space removed. I'd suggest attaching the comments to the >>>> next following token (for example {atom,Line,theAtom} should become >>>> {atom, Line, theAtom, "the preceding comments and white space"} >>>> It should be possible to *exactly* reconstruct the input from the parse >>>> tree. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 5) We should decide how to attach "floating" comments in the source. >>>> Does a comment *before* a function apply to the next function or not? >>>> >>>> 6) We need some "injection" API to inject code, meta-data, examples >>>> and documentations into a data base. >>>> >>>> For example inject:code("foo.erl") should inject a load of key/value >>>> pairs into a data base, with something like the following keys >>>> >>>> {text, Mod,Func,Arity} => the source code text >>>> {spec, Mod, Func, Arity} => the spec >>>> {doc, Mod,Func,Arity} => the documentation >>>> {examples,Mod,Func,Arity} = [Examples] >>>> >>>> The entities in the database should be sufficient to reconstruct the >>>> original text, and perform various analysis of the functions. >>>> >>>> I think *most* of the problems involved are due to the difficulty of >>>> extracting information from the source files and editing this when it is >>>> wrong. >>>> >>>> I'm currently trying to do parts of this. >>>> >>>> A "relatively simple" program should be able to (for a given function) >>>> >>>> - find the exact source text >>>> - find all old versions >>>> - find the specs and types referred to >>>> - find the documentation >>>> - find the test cases >>>> >>>> Doing so involves analysing the erlang sources the XML sources and the >>>> test cases, and involves a deal of guess work. >>>> >>>> All this must be done on a moving target and should not break the >>>> existing system. >>>> >>>> I suspect that the code to accurately manipulate the code and >>>> documentation have been has been written several times in different >>>> projects (for example >>>> the wrangler, and the Eclipse interface) both need to manipulate the >>>> source >>>> in various ways. >>>> >>>> >>>> >>>> >>>> On Mon, Sep 26, 2016 at 6:41 PM, wrote: >>>>> Joe, >>>>> >>>>> You've said so well what I've been trying to harp on. >>>>> >>>>> My most recent timesink has been trying to understand xmerl sufficiently >>>>> well to pull book data out of several different book APIs. Dave Thomas's >>>>> 2007 tutorial has been a big help, but the black holes in my understanding >>>>> still significantly impede my progress. So far I've spent maybe 10 to 15 >>>>> hours trying to scope it out. I can get much of what I need from Amazon's >>>>> APIs, but I need a redundant source. The Library of Congress API completely >>>>> eludes me; I get a little further with ISBNdb, but still not far enough. >>>>> >>>>> Given discussion on the documentation thread to date, it seems to me >>>>> that there are four issues at stake: >>>>> >>>>> 1) Content deficiencies >>>>> 2) Formatting issues >>>>> 3) Lack of consensus of what we, as a community, want >>>>> 4) How we move forward toward comprehensive improvement of >>>>> documentation. >>>>> >>>>> Lukas Larsson's most recent post makes a good point. >>>>> >>>>> Bruce Yinhe tells me in a private post that his group is about to hire >>>>> one person on a part-time basis to work on documentation improvements. >>>>> >>>>> I've lost it in the thread, but as I recall we had some promising >>>>> interest in documentation improvements from an Erricson employee. >>>>> >>>>> It would be great if we could begin to rally around these comments and >>>>> find some kind of convergence toward progress. >>>>> >>>>> My take is to break the large task down into small chunks, bring the >>>>> intelligence and resources of the community to bear on one specific issue at >>>>> a time and, and get it done. >>>> I think many (most) of the problems arise because what we are ultimately >>>> doing is changing the content of a file at some place. >>>> >>>> Fixing a typo/bug involves >>>> >>>> 1- finding the appropriate file >>>> 2 - changing the file at the appropriate place >>>> 3 - updating the file (somehow) >>>> 4 - generating the downstream documents that depend upon the file >>>> >>>> All these steps are difficult >>>> >>>> We can imagine a simpler way: >>>> >>>> Suppose a file is a sequence of paragraphs. Each paragraph >>>> has a GUId >>>> >>>> In (say) HTML >>>> >>>>

>>>> This is my paragarph ... >>>>

>>>> >>>> If I want to update the paragraphs I just send a message >>>> >>>> {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" >>>> "the new content"} >>>> >>>> to some server - this should be checked (manually) and then >>>> if approved used to update everything. >>>> >>>> In other threads I have argued that *everything* should be in a global >>>> database with a huge DHT tracking where things are. >>>> >>>> A key to "changing things" is "naming things" and "finding things" >>>> >>>> yes another (even simpler) alternative is to have a message >>>> >>>> {change,SHA,NewText} >>>> >>>> Meaning "change the paragraph with sha1 checksum to " >>>> >>>> Implementing this is easy - BUT all paragraphs with the same SHA >>>> would be changed - which might not be what we want. >>>> >>>> I have (incidentally) experimented with this - tagging all paragraphs >>>> with their SHAs and sticking the results in a database. >>>> >>>> >>>> make a server that accepts messages of the form >>>> >>>> {change, , } >>>> >>>> The server finds a paragraph with sha1 checksum and changes >>>> it to - it changes the appropriate file in a GIT archive >>>> does all the /add/commit/push magic and the job is done. >>>> >>>> (I think I'll implement this for fun :-) >>>> >>>> >>>> >>>>> I don't have the technical chops, but I'll gladly work with you or >>>>> anyone else to address content issues on a module-by-module basis. I can ask >>>>> Micky-the_Dunce questions and, perhaps, help clarify language. It would be >>>>> great if you could help clarify intent and application issues. >>>>> >>>>> All the best, >>>>> >>>>> Lloyd >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: "Joe Armstrong" >>>>> Sent: Monday, September 26, 2016 6:42am >>>>> To: "Lukas Larsson" >>>>> Cc: "Lloyd R. Prentice" , >>>>> "erlang-questions@REDACTED" >>>>> Subject: Re: [erlang-questions] Erlang documentation -- a modest >>>>> proposal >>>>> >>>>> I think what I miss most are *examples* >>>>> >>>>> I've just been reading the edoc manual pages for a program >>>>> called (name changed to avoid embarrassment) >>>>> >>>>> The functions are well documented - they types are well documented >>>>> but I haven't a clue about which ORDER to call the functions >>>>> >>>>> Imagine a file system. >>>>> >>>>> We *document* the open, read, write, and close functions >>>>> but we don't say you have to open the file before we read it. >>>>> We dont say when we're done we have to close the file. >>>>> >>>>> We don't say this because it is *obvious* >>>>> >>>>> But for the module glonk, which exports, zizzle, taddle, glonk and plonk >>>>> it is NOT obvious. Yes sure you all know you have to call glonk 3 times >>>>> before calling plonk - but I don't know. >>>>> >>>>> Thats why we need examples. >>>>> >>>>> Often I search for a tutorial and find a ten line blog posting that >>>>> actually shows me how to use a library - this gets me started. >>>>> >>>>> very short unit tests - placed inline are *very* useful >>>>> >>>>> for example: >>>>> >>>>> "321" = lists:reverse("123") >>>>> >>>>> The unit test *are* the examples - what we don't have is software that >>>>> parses the code, parses the documentation, parses the unit test >>>>> and munges all together into a form that is convenient to read. >>>>> >>>>> I'm actually trying to write something like this now - hence my wails >>>>> of anguish over css. >>>>> >>>>> Wish me luck >>>>> >>>>> /Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson >>>>> wrote: >>>>>> Hello, >>>>>> >>>>>> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice >>>>>> >>>>>> wrote: >>>>>>> Hello, >>>>>>> >>>>>>> To date, this thread has generated quite a few worthwhile insights and >>>>>>> ideas. My fear is that they will be deep-sixed into the archive. On >>>>>>> the >>>>>>> other hand, major revision is a daunting task and unlikely to happen. >>>>>>> >>>>>>> But maybe we can focus on specific issues and make iterative headway. >>>>>>> >>>>>>> Fewer than half of the functions in the lists library, for instance, >>>>>>> have >>>>>>> code examples. Suppose over the span of one week we were collectively >>>>>>> focus >>>>>>> on generating at least two code examples for each function in one >>>>>>> library. >>>>>>> >>>>>>> At the end of the week we could organize the submissions and vote on >>>>>>> best >>>>>>> candidates for inclusion in the docs. That done, we can pick another >>>>>>> module. >>>>>>> >>>>>>> Thus, with not much effort from any one individual, a small posse of >>>>>>> volunteer Erlang wizards could make short work of deficiencies in the >>>>>>> docs. >>>>>>> >>>>>>> Anyway, it's an idea. >>>>>>> >>>>>>> All the best, >>>>>>> >>>>>>> LRP >>>>>>> >>>>>> I think that it is great to see everyone talking about wanting to >>>>>> improve >>>>>> the documentation. The contributions to the Erlang/OTP project that I >>>>>> value >>>>>> that most are documentation changes that make the intention clearer, or >>>>>> explains some corner case somewhere which the docs did not initially >>>>>> mention. >>>>>> >>>>>> Unfortunately, once one has figured out how a function works there >>>>>> seems to >>>>>> be very little incentive to make the docs clearer. I would estimate >>>>>> that >>>>>> about every 20th pull request we get is a documentation fix, and more >>>>>> than >>>>>> half of those are fixes of speling misstakes (which are great!). >>>>>> >>>>>> I've just come back from about two weeks of vacation and this >>>>>> discussion has >>>>>> resulted in roughly 0 pull requests for changes in the documentation. >>>>>> Would >>>>>> it be possible to steer this discussion into doing something instead of >>>>>> talking about doing something? Yes the technology/layout is not >>>>>> perfect, but >>>>>> as Lo?c said, it is the content that matters the most. >>>>>> >>>>>> Lukas >>>>>> // my own oppinions >>>>>> >>>>>> _______________________________________________ >>>>>> 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 kenneth@REDACTED Tue Sep 27 09:44:41 2016 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 27 Sep 2016 09:44:41 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: Hi, I have followed this thread with interest since there are many good suggestions and ideas. As Lukas mentioned it would be good if we could agree on some action(s) in which the community could contribute. First some info about what we (The OTP team at Ericsson and the Industrial Erlang User Group) plan to do. - Nicer , better HTML layout of the docs. The Elixir look layout looks quite nice and since it is overlapping communities it could be good to have the same or similar layout. The HTML, CSS, Javascript setup seems quite well thought. Take a look at http://elixir-lang.org/docs/stable/elixir/Kernel.html# full-list. If you have suggestions regarding the html layout they are welcome. In that case it would be nice with a small example showing for example the beginning of the lists module and a few functions. Note this step does not require changes of the doc source which is XML it is just a matter of tooling. Translating the current XML to html (when you know what html you want). - Making it easier to contribute with documentation improvements. One simple step can be to add a link to the doc source at github from the generated html page. Another to write a short guide on how to contribute to the documentation. - Having technical writers going through the documentation in order to correct language and consistency. This is ongoing. - Making the search in documentation on www.erlang.org more visible. You can search on application, modules, functions. - Validate the current doc sources with XMLLINT to assure that we are following our own DTDs. This is almost done and with this in place it is easy to translate the doc sources to some other format like a simpler XML dtd (or XSD), asciidoc or even markdown. Note that there is only one common source for the documentation and it is in XML with a few exceptions. Each application has a doc/src directory where its documentation source files are. There is module references for the modules with public APIs and a User Guide (mostly). >From this thread I think the following are the most interesting suggestions: Examples in the doc ------------------------------ I agree that we need more examples in the documentation. It would for example be good to have a short example for almost every function in a module. This can be done in various ways. Either embed the example in the text or have a separate example file in parallell with the text. In both cases I would like to have the possibility to automatically check the syntax and execution of the example during the build documentation build process. If not checked we will soon have a number of non working examples. The presentation view of examples is just a tooling question independent on the actual source for the examples. The first thing is to create the source for examples and what format we should use for this (same for all modules of course). Man pages or not? ------------------------- I understand that some of you are using the man pages. But the question is why are you using them? Is it because it is easy to type "man lists" or "erl -man lists"? What if "erl -man lists" pops up in a web-browser window of you choice instead?, Note that it is exactly the same information shown in the lists.html and in the man page for lists. PDF or not? ------------------ I think it is rather unusual that the PDF pages we generate to day are used compared to the HTML variant. Correct me if I am wrong. Perhaps Epub or something else would be more useful. I suppose the html variant could also support printing and or saving as pdf without to much effort from our side. More User Guide oriented text or cook books. --------------------------------------------------------------- This is very valuable but does not have to be part of the Erlang/OTP release. Could be hosted on a web-site like Erlang Central (and there is already material like this there I think). I have probably forgotten lots of things that I should have mentioned and commented , but this is it for now. /Kenneth, Erlang/OTP , Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Sep 27 10:39:58 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 27 Sep 2016 10:39:58 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> On 09/27/2016 09:44 AM, Kenneth Lundin wrote: > Man pages or not? > ------------------------- > > I understand that some of you are using the man pages. But the question > is why are you using them? > Is it because it is easy to type "man lists" or "erl -man lists"? What > if "erl -man lists" pops up in a web-browser window of you choice > instead?, Note that it is exactly the same information shown in the > lists.html and in the man page for lists. It would be terrible for many reasons: * lack of search; command line manual search is very useful (man -k and others) * man pages are readable in 80x24 windows; browsers aren't * opening in a separate window is awkward; currently I need to do this to have what I need: Menu key (opens a terminal), "man lists"; with what you suggest I need at least a couple more steps * if i want to have the manual side by side with the code, I need a different browser or browser window; I already fight with Dialyzer because it runs out of memory on some modules, I don't need the waste browsers add on top of that Also note that in the absence of man pages, I'd look first into 'info' or PDF formats before I consider local HTML. HTML is just not practical for manuals. I'm also wondering why the intent to remove man/PDF formats. They're already working, it doesn't sound like they would need much maintenance to be kept, they have users, so why consider removing them? It doesn't make much sense to me. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From kenneth@REDACTED Tue Sep 27 11:08:39 2016 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 27 Sep 2016 11:08:39 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: On Tue, Sep 27, 2016 at 10:39 AM, Lo?c Hoguin wrote: > On 09/27/2016 09:44 AM, Kenneth Lundin wrote: > >> Man pages or not? >> ------------------------- >> >> I understand that some of you are using the man pages. But the question >> is why are you using them? >> Is it because it is easy to type "man lists" or "erl -man lists"? What >> if "erl -man lists" pops up in a web-browser window of you choice >> instead?, Note that it is exactly the same information shown in the >> lists.html and in the man page for lists. >> > > It would be terrible for many reasons: > > * lack of search; command line manual search is very useful (man -k and > others) > I don't think the search has to be worse in the html form, it depends on how we do it. > * man pages are readable in 80x24 windows; browsers aren't > Have you tried lynx? a text based web-browser I think our html pages looks quite good in that one. > * opening in a separate window is awkward; currently I need to do this to > have what I need: Menu key (opens a terminal), "man lists"; with what you > suggest I need at least a couple more steps > * if i want to have the manual side by side with the code, I need a > different browser or browser window; I already fight with Dialyzer because > it runs out of memory on some modules, I don't need the waste browsers add > on top of that > > Also note that in the absence of man pages, I'd look first into 'info' or > PDF formats before I consider local HTML. HTML is just not practical for > manuals. > > I'm also wondering why the intent to remove man/PDF formats. They're > already working, it doesn't sound like they would need much maintenance to > be kept, they have users, so why consider removing them? It doesn't make > much sense to me. html, pdf and man are 3 different backends for generating documentation of course it will cost more to maintain and develop 3 backends instead of 1 or 2. This is especially true if new features are introduced in the document source format or if we even change the format completely. But this is just a possibility (to remove formats that are not so much used) , no decision is taken. Interesting would be to know how many % of the users that actually are using the man and pdf pages. /Kenneth, Erlang/OTP Ericsson > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zkessin@REDACTED Tue Sep 27 11:19:53 2016 From: zkessin@REDACTED (Zachary Kessin) Date: Tue, 27 Sep 2016 12:19:53 +0300 Subject: [erlang-questions] Running a Unix Subprocess Message-ID: Hi all I want to run a sub process that will connect via StdIn and StdOut. Is there an easy way to do this? I had thought to use a port but as the child process was not written with the assumption that it is running inside a port i don't want to have to prepend length bytes onto the inputs and outputs. Is there an easy way to do this in erlang? -- Zach Kessin SquareTarget Twitter: @zkessin Skype: zachkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Tue Sep 27 11:26:36 2016 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Tue, 27 Sep 2016 12:26:36 +0300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: On Tue, Sep 27, 2016 at 12:08 PM, Kenneth Lundin wrote: > > > On Tue, Sep 27, 2016 at 10:39 AM, Lo?c Hoguin wrote: >> >> On 09/27/2016 09:44 AM, Kenneth Lundin wrote: >>> >>> Man pages or not? >>> ------------------------- >>> >>> I understand that some of you are using the man pages. But the question >>> is why are you using them? >>> Is it because it is easy to type "man lists" or "erl -man lists"? What >>> if "erl -man lists" pops up in a web-browser window of you choice >>> instead?, Note that it is exactly the same information shown in the >>> lists.html and in the man page for lists. >> >> >> It would be terrible for many reasons: >> >> * lack of search; command line manual search is very useful (man -k and >> others) > > I don't think the search has to be worse in the html form, it depends on how > we do it. > >> >> * man pages are readable in 80x24 windows; browsers aren't > > Have you tried lynx? a text based web-browser I think our html pages looks > quite good in that one. > >> >> * opening in a separate window is awkward; currently I need to do this to >> have what I need: Menu key (opens a terminal), "man lists"; with what you >> suggest I need at least a couple more steps >> * if i want to have the manual side by side with the code, I need a >> different browser or browser window; I already fight with Dialyzer because >> it runs out of memory on some modules, I don't need the waste browsers add >> on top of that >> >> Also note that in the absence of man pages, I'd look first into 'info' or >> PDF formats before I consider local HTML. HTML is just not practical for >> manuals. >> >> I'm also wondering why the intent to remove man/PDF formats. They're >> already working, it doesn't sound like they would need much maintenance to >> be kept, they have users, so why consider removing them? It doesn't make >> much sense to me. > > > html, pdf and man are 3 different backends for generating documentation of > course it will cost more to maintain and develop 3 backends instead of 1 or > 2. This is especially true if new features are introduced in the document > source format or if we even change the format completely. > > But this is just a possibility (to remove formats that are not so much used) > , no decision is taken. > > Interesting would be to know how many % of the users that actually are using > the man and pdf pages. > I am using man format, when I need to work offline. Karolis > /Kenneth, Erlang/OTP Ericsson >> >> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> Author of The Erlanger Playbook, >> A book about software development using Erlang >> _______________________________________________ >> 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 ameretat.reith@REDACTED Tue Sep 27 11:34:26 2016 From: ameretat.reith@REDACTED (Ameretat Reith) Date: Tue, 27 Sep 2016 13:04:26 +0330 Subject: [erlang-questions] Running a Unix Subprocess In-Reply-To: References: Message-ID: <20160927130426.11a0aed1@gmail.com> On Tue, 27 Sep 2016 12:19:53 +0300 Zachary Kessin wrote: > Hi all > > I want to run a sub process that will connect via StdIn and StdOut. Is > there an easy way to do this? I had thought to use a port but as the > child process was not written with the assumption that it is running > inside a port i don't want to have to prepend length bytes onto the > inputs and outputs. > > Is there an easy way to do this in erlang? > User erlang:open_port [1]. Example: erlang:open_port({spawn_executable, "/bin/cat"}, [eof, exit_status]). This will open a port and execute "/bin/cat" in it, wait until standard input is closed (eof), reply exit status after cat termination (exit_status). If you want process get standard input and output of caller, pass use_stdio option. 1: http://erlang.org/doc/man/erlang.html#open_port-2 From erlang@REDACTED Tue Sep 27 11:46:08 2016 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 27 Sep 2016 11:46:08 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: Re: HTML I'd very much like to mock up a "nice" HTML display of the functions in a module. What I'd like is for most of the information to be initially hidden and to be made available through clickable folds or hover popups. Doing this involves a few different problems: 1) - extracting the necessary information to be displayed from the XML or erlang sources 2) - turning 1) into HTML markup 3) - adding some CSS/JS magic to create hover popups/folds and so on. I have a good idea how to do 1) - step 2) is easy if I know what markup to produce. I'm rubbish at step 3) I guess there must be someone reading this list who is skilled in the art of CSS/JS and could suggest a suitable markup. Being a tad fussy about these things I wonder if it's possible to get a pretty display *without* including 200KB of JS libraries and CSS stuff. If some kind people could mockup a a few pages with dummy markup it might help move things along Cheers /Joe On Tue, Sep 27, 2016 at 9:44 AM, Kenneth Lundin wrote: > Hi, > > I have followed this thread with interest since there are many good > suggestions and ideas. As Lukas mentioned it would be good if we could agree > on some action(s) in which the community could contribute. > > First some info about what we (The OTP team at Ericsson and the Industrial > Erlang User Group) plan to do. > > - Nicer , better HTML layout of the docs. The Elixir look layout looks quite > nice and since it is overlapping communities it could be good to have the > same or similar layout. The HTML, CSS, Javascript setup seems quite well > thought. > Take a look at > http://elixir-lang.org/docs/stable/elixir/Kernel.html#full-list. > If you have suggestions regarding the html layout they are welcome. In that > case it would be nice with a small example showing for example the beginning > of the lists module and a few functions. Note this step does not require > changes of the doc source which is XML it is just a matter of tooling. > Translating the current XML to html (when you know what html you want). > > - Making it easier to contribute with documentation improvements. One simple > step can be to add a link to the doc source at github from the generated > html page. Another to write a short guide on how to contribute to the > documentation. > > - Having technical writers going through the documentation in order to > correct language and consistency. This is ongoing. > > - Making the search in documentation on www.erlang.org more visible. You can > search on application, modules, functions. > > - Validate the current doc sources with XMLLINT to assure that we are > following our own DTDs. This is almost done and with this in place it is > easy to translate the doc sources to some other format like a simpler XML > dtd (or XSD), asciidoc or even markdown. Note that there is only one common > source for the documentation and it is in XML with a few exceptions. Each > application has a doc/src directory where its documentation source files > are. There is module references for the modules with public APIs and a User > Guide (mostly). > > From this thread I think the following are the most interesting suggestions: > > Examples in the doc > ------------------------------ > > I agree that we need more examples in the documentation. It would for > example be good to have a short example for > almost every function in a module. > > This can be done in various ways. Either embed the example in the text or > have a separate example file in parallell with the text. In both cases I > would like to have the possibility to automatically check the syntax and > execution of the example during the build documentation build process. If > not checked we will soon have a number of non working examples. > > The presentation view of examples is just a tooling question independent on > the actual source for the examples. The first thing is to create the source > for examples and what format we should use for this (same for all modules of > course). > > Man pages or not? > ------------------------- > > I understand that some of you are using the man pages. But the question is > why are you using them? > Is it because it is easy to type "man lists" or "erl -man lists"? What if > "erl -man lists" pops up in a web-browser window of you choice instead?, > Note that it is exactly the same information shown in the lists.html and in > the man page for lists. > > PDF or not? > ------------------ > > I think it is rather unusual that the PDF pages we generate to day are used > compared to the HTML variant. Correct me if I am wrong. > Perhaps Epub or something else would be more useful. I suppose the html > variant could also support printing and or saving as pdf without to much > effort from our side. > > More User Guide oriented text or cook books. > --------------------------------------------------------------- > > This is very valuable but does not have to be part of the Erlang/OTP > release. Could be hosted on a web-site like Erlang Central (and there is > already material like this there I think). > > I have probably forgotten lots of things that I should have mentioned and > commented , but this is it for now. > > /Kenneth, Erlang/OTP , Ericsson > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From igor.clark@REDACTED Tue Sep 27 11:58:05 2016 From: igor.clark@REDACTED (Igor Clark) Date: Tue, 27 Sep 2016 10:58:05 +0100 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: Hello wizards, On 27/09/2016 10:08, Kenneth Lundin wrote: > Interesting would be to know how many % of the users that actually are > using the man and pdf pages. I mostly just lurk on this list, trying to pick up pearls from the sidelines, but for what it's worth, I use the man pages heavily when writing erlang. Maybe even saying I rely on them isn't too strong. They're fantastic, and I'd be really sad if they went away. I definitely use the online HTML manuals a lot when planning, designing and working out how to do things, and take the PDFs with me when on a flight or long journey - but when actually writing code, the man pages are invaluable. They form a concise, specific and appropriately terse reference that's right there when you need it, and the context-switch of having to swap from terminals to browsers just to look up "what was the signature for that function, again?" (a regular occurrence for me, especially with a platform of erlang/OTP's sheer scale) is just yet more load that my old brain could do without. I'm sure I could get used to using lynx with some alias or other, but I'd rather not have to, and I'd much rather have the man pages available on my disk, without relying on the network. Honestly I wish more platforms had the kind of reference support that erlang's man pages give it. I absolutely agree that the pithy-example content that Joe and Lo?c have suggested would be great, and maybe different formatting/layouts alongside a re-org for some of the doc structure would be helpful - but for me, not so much that either would warrant taking away 'erl -man', if there's a choice to be made. Anyway, as always, thanks for the amazing platform *and* its documentation, Igor From essen@REDACTED Tue Sep 27 11:59:51 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 27 Sep 2016 11:59:51 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: <5f956382-95b6-5cf8-f7cc-04d6a8354f20@ninenines.eu> On 09/27/2016 11:08 AM, Kenneth Lundin wrote: > * lack of search; command line manual search is very useful (man -k > and others) > > I don't think the search has to be worse in the html form, it depends on > how we do it. I'm not sure how you would get the equivalent of the erldoc online search in static html files. Unless you mean doing something like "erl -mansearch term" which is yet another custom thing to write. > * man pages are readable in 80x24 windows; browsers aren't > > Have you tried lynx? a text based web-browser I think our html pages > looks quite good in that one. I don't find it anywhere close to man pages usability. The lack of indentation between function name, types, description etc. makes it very difficult to make out what is what, especially considering the bold is also gone from the function name. Nearly unreadable. Not to mention it's not very good for navigating inside the page (by default at least). > * opening in a separate window is awkward; currently I need to do > this to have what I need: Menu key (opens a terminal), "man lists"; > with what you suggest I need at least a couple more steps > * if i want to have the manual side by side with the code, I need a > different browser or browser window; I already fight with Dialyzer > because it runs out of memory on some modules, I don't need the > waste browsers add on top of that > > Also note that in the absence of man pages, I'd look first into > 'info' or PDF formats before I consider local HTML. HTML is just not > practical for manuals. > > I'm also wondering why the intent to remove man/PDF formats. They're > already working, it doesn't sound like they would need much > maintenance to be kept, they have users, so why consider removing > them? It doesn't make much sense to me. > > > html, pdf and man are 3 different backends for generating documentation > of course it will cost more to maintain and develop 3 backends instead > of 1 or 2. This is especially true if new features are introduced in the > document source format or if we even change the format completely. That's the thing. You shouldn't have to maintain 3 different backends. You have all this because long ago you (OTP team) decided to roll your own instead of using existing formats and tooling. Joe said DocBook is too big for your purposes, but the only big thing I see is the amount of custom code you have in erl_docgen. :-) The way most people do documentation today is to have one input format (Asciidoc, ReST, DocBook, TexInfo...) and to use the associated tooling to generate various output formats. In Asciidoc that means using a2x, which generates DocBook and from there pretty much any format is possible with next to zero effort: * man, PDF, HTML, chunked HTML are built-in, one command needed * mobi and epub need one extra command * info needs an intermediate file to be kept; then it's one more command If you need more than stylesheets and configuration, then something is not right. You shouldn't have to maintain 3 different backends. If you change the format completely, then I don't see how different output formats is going to be a problem, unless you choose to roll your own again, or you choose (gasp!) Markdown. But even then Pandoc can help in the worst case scenario. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From martin@REDACTED Tue Sep 27 13:03:39 2016 From: martin@REDACTED (Martin Karlsson) Date: Wed, 28 Sep 2016 00:03:39 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: Hi guys, > Interesting would be to know how many % of the users that actually are using the man and pdf pages. The man pages is the erlang documentation I use the most. In fact I Iike them so much I had to reply to this thread to reduce the risk of them going away :). They are much quicker than anything if you have a console based work-flow. I even miss the man pages for all external libraries. I would love if there was a common erlang documentation system making it easy for external libraries to produce the same style and type of documentation as the official documentation. I am not overly attached to a documentation system but there are a few that does conversion to lots of formats with good quality, for example sphinx which can generate html, latex, man pages, epub among others. A final comment regarding html generated documentation. Please don't rely on javascript for more than enhancing the experience. I see lots of modern html documentation which doesn't display all data (for example code examples) or can't do navigation without javascript. Cheers, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From random.outcomes@REDACTED Tue Sep 27 13:11:41 2016 From: random.outcomes@REDACTED (Luke) Date: Tue, 27 Sep 2016 21:11:41 +1000 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: Joe, check out this startup - https://www.simpla.io/ They allow editable web pages, which creates blobs which get saves directly into a database. No more digging through source files to edit docs, people (with appropriate permission) can edit the page live. It would be very straightforward to write a program to dump from the database to XML/JSON or whatever format you're interested in, making it portable, and fairly trivial to go the other way. (Full disclosure: It's not my startup but they're my mates, we went through the same accelerator). Is the raw XML documentation available anywhere? Thanks, Luke On Tue, Sep 27, 2016 at 6:03 AM, Joe Armstrong wrote: > Regarding the documentation - there is a step0 that needs to be done > *before* attacking the document improvement problem. > > The following things are needed (I my opinion) > > 1) The number of DTDs in the documentation should be reduced to ONE > there are currently 26 these are in > otp_src_/lib/erl_docgen/priv/dtd > > 2) tags that are used infrequently should be removed and the source XML > corrected. Some tags are virtually *never* used. > > 3) All XML files should validate with the new DTD > > These steps need quite a lot of work ... > > 4) The Erlang parser should be changed to exactly > reproduce the source. > Right now the parse tree of correct erlang has all the comments > and white space removed. I'd suggest attaching the comments to the > next following token (for example {atom,Line,theAtom} should become > {atom, Line, theAtom, "the preceding comments and white space"} > It should be possible to *exactly* reconstruct the input from the parse > tree. > > > > > > > > 5) We should decide how to attach "floating" comments in the source. > Does a comment *before* a function apply to the next function or not? > > 6) We need some "injection" API to inject code, meta-data, examples > and documentations into a data base. > > For example inject:code("foo.erl") should inject a load of key/value > pairs into a data base, with something like the following keys > > {text, Mod,Func,Arity} => the source code text > {spec, Mod, Func, Arity} => the spec > {doc, Mod,Func,Arity} => the documentation > {examples,Mod,Func,Arity} = [Examples] > > The entities in the database should be sufficient to reconstruct the > original text, and perform various analysis of the functions. > > I think *most* of the problems involved are due to the difficulty of > extracting information from the source files and editing this when it is > wrong. > > I'm currently trying to do parts of this. > > A "relatively simple" program should be able to (for a given function) > > - find the exact source text > - find all old versions > - find the specs and types referred to > - find the documentation > - find the test cases > > Doing so involves analysing the erlang sources the XML sources and the > test cases, and involves a deal of guess work. > > All this must be done on a moving target and should not break the > existing system. > > I suspect that the code to accurately manipulate the code and > documentation have been has been written several times in different > projects (for example > the wrangler, and the Eclipse interface) both need to manipulate the source > in various ways. > > > > > On Mon, Sep 26, 2016 at 6:41 PM, wrote: > > Joe, > > > > You've said so well what I've been trying to harp on. > > > > My most recent timesink has been trying to understand xmerl sufficiently > well to pull book data out of several different book APIs. Dave Thomas's > 2007 tutorial has been a big help, but the black holes in my understanding > still significantly impede my progress. So far I've spent maybe 10 to 15 > hours trying to scope it out. I can get much of what I need from Amazon's > APIs, but I need a redundant source. The Library of Congress API completely > eludes me; I get a little further with ISBNdb, but still not far enough. > > > > Given discussion on the documentation thread to date, it seems to me > that there are four issues at stake: > > > > 1) Content deficiencies > > 2) Formatting issues > > 3) Lack of consensus of what we, as a community, want > > 4) How we move forward toward comprehensive improvement of documentation. > > > > Lukas Larsson's most recent post makes a good point. > > > > Bruce Yinhe tells me in a private post that his group is about to hire > one person on a part-time basis to work on documentation improvements. > > > > I've lost it in the thread, but as I recall we had some promising > interest in documentation improvements from an Erricson employee. > > > > It would be great if we could begin to rally around these comments and > find some kind of convergence toward progress. > > > > My take is to break the large task down into small chunks, bring the > intelligence and resources of the community to bear on one specific issue > at a time and, and get it done. > > I think many (most) of the problems arise because what we are ultimately > doing is changing the content of a file at some place. > > Fixing a typo/bug involves > > 1- finding the appropriate file > 2 - changing the file at the appropriate place > 3 - updating the file (somehow) > 4 - generating the downstream documents that depend upon the file > > All these steps are difficult > > We can imagine a simpler way: > > Suppose a file is a sequence of paragraphs. Each paragraph > has a GUId > > In (say) HTML > >

> This is my paragarph ... >

> > If I want to update the paragraphs I just send a message > > {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" > "the new content"} > > to some server - this should be checked (manually) and then > if approved used to update everything. > > In other threads I have argued that *everything* should be in a global > database with a huge DHT tracking where things are. > > A key to "changing things" is "naming things" and "finding things" > > yes another (even simpler) alternative is to have a message > > {change,SHA,NewText} > > Meaning "change the paragraph with sha1 checksum to " > > Implementing this is easy - BUT all paragraphs with the same SHA > would be changed - which might not be what we want. > > I have (incidentally) experimented with this - tagging all paragraphs > with their SHAs and sticking the results in a database. > > > make a server that accepts messages of the form > > {change, , } > > The server finds a paragraph with sha1 checksum and changes > it to - it changes the appropriate file in a GIT archive > does all the /add/commit/push magic and the job is done. > > (I think I'll implement this for fun :-) > > > > > > > I don't have the technical chops, but I'll gladly work with you or > anyone else to address content issues on a module-by-module basis. I can > ask Micky-the_Dunce questions and, perhaps, help clarify language. It would > be great if you could help clarify intent and application issues. > > > > All the best, > > > > Lloyd > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: "Joe Armstrong" > > Sent: Monday, September 26, 2016 6:42am > > To: "Lukas Larsson" > > Cc: "Lloyd R. Prentice" , " > erlang-questions@REDACTED" > > Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal > > > > I think what I miss most are *examples* > > > > I've just been reading the edoc manual pages for a program > > called (name changed to avoid embarrassment) > > > > The functions are well documented - they types are well documented > > but I haven't a clue about which ORDER to call the functions > > > > Imagine a file system. > > > > We *document* the open, read, write, and close functions > > but we don't say you have to open the file before we read it. > > We dont say when we're done we have to close the file. > > > > We don't say this because it is *obvious* > > > > But for the module glonk, which exports, zizzle, taddle, glonk and plonk > > it is NOT obvious. Yes sure you all know you have to call glonk 3 times > > before calling plonk - but I don't know. > > > > Thats why we need examples. > > > > Often I search for a tutorial and find a ten line blog posting that > > actually shows me how to use a library - this gets me started. > > > > very short unit tests - placed inline are *very* useful > > > > for example: > > > > "321" = lists:reverse("123") > > > > The unit test *are* the examples - what we don't have is software that > > parses the code, parses the documentation, parses the unit test > > and munges all together into a form that is convenient to read. > > > > I'm actually trying to write something like this now - hence my wails > > of anguish over css. > > > > Wish me luck > > > > /Joe > > > > > > > > > > > > > > > > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson > wrote: > >> Hello, > >> > >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice < > lloyd@REDACTED> > >> wrote: > >>> > >>> Hello, > >>> > >>> To date, this thread has generated quite a few worthwhile insights and > >>> ideas. My fear is that they will be deep-sixed into the archive. On the > >>> other hand, major revision is a daunting task and unlikely to happen. > >>> > >>> But maybe we can focus on specific issues and make iterative headway. > >>> > >>> Fewer than half of the functions in the lists library, for instance, > have > >>> code examples. Suppose over the span of one week we were collectively > focus > >>> on generating at least two code examples for each function in one > library. > >>> > >>> At the end of the week we could organize the submissions and vote on > best > >>> candidates for inclusion in the docs. That done, we can pick another > module. > >>> > >>> Thus, with not much effort from any one individual, a small posse of > >>> volunteer Erlang wizards could make short work of deficiencies in the > docs. > >>> > >>> Anyway, it's an idea. > >>> > >>> All the best, > >>> > >>> LRP > >>> > >> > >> I think that it is great to see everyone talking about wanting to > improve > >> the documentation. The contributions to the Erlang/OTP project that I > value > >> that most are documentation changes that make the intention clearer, or > >> explains some corner case somewhere which the docs did not initially > >> mention. > >> > >> Unfortunately, once one has figured out how a function works there > seems to > >> be very little incentive to make the docs clearer. I would estimate that > >> about every 20th pull request we get is a documentation fix, and more > than > >> half of those are fixes of speling misstakes (which are great!). > >> > >> I've just come back from about two weeks of vacation and this > discussion has > >> resulted in roughly 0 pull requests for changes in the documentation. > Would > >> it be possible to steer this discussion into doing something instead of > >> talking about doing something? Yes the technology/layout is not > perfect, but > >> as Lo?c said, it is the content that matters the most. > >> > >> Lukas > >> // my own oppinions > >> > >> _______________________________________________ > >> 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 kenneth@REDACTED Tue Sep 27 13:13:37 2016 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 27 Sep 2016 13:13:37 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: Hi Joe, Have you looked at the Elixir doc for example http://elixir-lang.org/docs/stable/elixir/Kernel.html? I think the layout and function is quite good and the handling of css and javascript is from what I can understand handled nicely. For an application and modules they present pretty much the same as we do today. For sure the Elixir community have more cometence around html, css, javascript than at least we on the OTP team have. The Elixir doc is genereated with a tool called Ex_doc written in Elixir of course. It takes Markdown as input but that is not important right now when we are discussing layout. The left column (the navigation) is generated as Json data that is handled by a fixed Javascript. There is also a search which takes Json data as input. This way everything including search can be handled locally in the browser without need for a web-server as far as I can see. On Tue, Sep 27, 2016 at 11:46 AM, Joe Armstrong wrote: > Re: HTML > > I'd very much like to mock up a "nice" HTML display of the functions > in a module. > Have you looked at the Elixir doc for example http://elixir-lang.org/docs/stable/elixir/Kernel.html? I think the layout and function is quite good and the handling of css and javascript is from what I can understand handled nicely. For an application and modules they present pretty much the same as we do today. For sure the Elixir community have more cometence around html, css, javascript than at least we on the OTP team have. The Elixir doc is genereated with a tool called Ex_doc written in Elixir of course. It takes Markdown as input but that is not important right now when we are discussing layout. The left column (the navigation) is generated as Json data that is handled by a fixed Javascript. There is also a search which takes Json data as input. This way everything including search can be handled locally in the browser without need for a web-server as far as I can see. > > What I'd like is for most of the information to be initially hidden > and to be made available through clickable folds or hover popups. > > Doing this involves a few different problems: > > 1) - extracting the necessary information to be displayed > from the XML or erlang sources > 2) - turning 1) into HTML markup > 3) - adding some CSS/JS magic to create hover popups/folds > and so on. > > I have a good idea how to do 1) - step 2) is easy if I know what markup > to produce. I'm rubbish at step 3) > > I guess there must be someone reading this list who is skilled in the > art of CSS/JS and could suggest a suitable markup. > > Being a tad fussy about these things I wonder if it's possible > to get a pretty display *without* including 200KB of JS libraries and CSS > stuff. > > If some kind people could mockup a a few pages with dummy markup > it might help move things along > > Cheers > > /Joe > /Kenneth > > > > > > > > On Tue, Sep 27, 2016 at 9:44 AM, Kenneth Lundin > wrote: > > Hi, > > > > I have followed this thread with interest since there are many good > > suggestions and ideas. As Lukas mentioned it would be good if we could > agree > > on some action(s) in which the community could contribute. > > > > First some info about what we (The OTP team at Ericsson and the > Industrial > > Erlang User Group) plan to do. > > > > - Nicer , better HTML layout of the docs. The Elixir look layout looks > quite > > nice and since it is overlapping communities it could be good to have the > > same or similar layout. The HTML, CSS, Javascript setup seems quite well > > thought. > > Take a look at > > http://elixir-lang.org/docs/stable/elixir/Kernel.html#full-list. > > If you have suggestions regarding the html layout they are welcome. In > that > > case it would be nice with a small example showing for example the > beginning > > of the lists module and a few functions. Note this step does not require > > changes of the doc source which is XML it is just a matter of tooling. > > Translating the current XML to html (when you know what html you want). > > > > - Making it easier to contribute with documentation improvements. One > simple > > step can be to add a link to the doc source at github from the generated > > html page. Another to write a short guide on how to contribute to the > > documentation. > > > > - Having technical writers going through the documentation in order to > > correct language and consistency. This is ongoing. > > > > - Making the search in documentation on www.erlang.org more visible. > You can > > search on application, modules, functions. > > > > - Validate the current doc sources with XMLLINT to assure that we are > > following our own DTDs. This is almost done and with this in place it is > > easy to translate the doc sources to some other format like a simpler XML > > dtd (or XSD), asciidoc or even markdown. Note that there is only one > common > > source for the documentation and it is in XML with a few exceptions. Each > > application has a doc/src directory where its documentation source files > > are. There is module references for the modules with public APIs and a > User > > Guide (mostly). > > > > From this thread I think the following are the most interesting > suggestions: > > > > Examples in the doc > > ------------------------------ > > > > I agree that we need more examples in the documentation. It would for > > example be good to have a short example for > > almost every function in a module. > > > > This can be done in various ways. Either embed the example in the text or > > have a separate example file in parallell with the text. In both cases I > > would like to have the possibility to automatically check the syntax and > > execution of the example during the build documentation build process. If > > not checked we will soon have a number of non working examples. > > > > The presentation view of examples is just a tooling question independent > on > > the actual source for the examples. The first thing is to create the > source > > for examples and what format we should use for this (same for all > modules of > > course). > > > > Man pages or not? > > ------------------------- > > > > I understand that some of you are using the man pages. But the question > is > > why are you using them? > > Is it because it is easy to type "man lists" or "erl -man lists"? What if > > "erl -man lists" pops up in a web-browser window of you choice instead?, > > Note that it is exactly the same information shown in the lists.html and > in > > the man page for lists. > > > > PDF or not? > > ------------------ > > > > I think it is rather unusual that the PDF pages we generate to day are > used > > compared to the HTML variant. Correct me if I am wrong. > > Perhaps Epub or something else would be more useful. I suppose the html > > variant could also support printing and or saving as pdf without to much > > effort from our side. > > > > More User Guide oriented text or cook books. > > --------------------------------------------------------------- > > > > This is very valuable but does not have to be part of the Erlang/OTP > > release. Could be hosted on a web-site like Erlang Central (and there is > > already material like this there I think). > > > > I have probably forgotten lots of things that I should have mentioned and > > commented , but this is it for now. > > > > /Kenneth, Erlang/OTP , Ericsson > > > > _______________________________________________ > > 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 kenneth.lundin@REDACTED Tue Sep 27 13:49:02 2016 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 27 Sep 2016 13:49:02 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: On Tue, Sep 27, 2016 at 1:11 PM, Luke wrote: > Joe, check out this startup - https://www.simpla.io/ > > They allow editable web pages, which creates blobs which get saves > directly into a database. No more digging through source files to edit > docs, people (with appropriate permission) can edit the page live. It would > be very straightforward to write a program to dump from the database to > XML/JSON or whatever format you're interested in, making it portable, and > fairly trivial to go the other way. (Full disclosure: It's not my startup > but they're my mates, we went through the same accelerator). > > Is the raw XML documentation available anywhere? > The documentation source is in the otp git repository. Each application has a doc/src directory with Makefile and .xml files. The system documentation is under Root/system/doc There are a few tweaks where the source is not XML but instead a Markdown file. /Kenneth > > Thanks, > Luke > > On Tue, Sep 27, 2016 at 6:03 AM, Joe Armstrong wrote: > >> Regarding the documentation - there is a step0 that needs to be done >> *before* attacking the document improvement problem. >> >> The following things are needed (I my opinion) >> >> 1) The number of DTDs in the documentation should be reduced to ONE >> there are currently 26 these are in >> otp_src_/lib/erl_docgen/priv/dtd >> >> 2) tags that are used infrequently should be removed and the source XML >> corrected. Some tags are virtually *never* used. >> >> 3) All XML files should validate with the new DTD >> >> These steps need quite a lot of work ... >> >> 4) The Erlang parser should be changed to exactly >> reproduce the source. >> Right now the parse tree of correct erlang has all the comments >> and white space removed. I'd suggest attaching the comments to the >> next following token (for example {atom,Line,theAtom} should become >> {atom, Line, theAtom, "the preceding comments and white space"} >> It should be possible to *exactly* reconstruct the input from the parse >> tree. >> >> >> >> >> >> >> >> 5) We should decide how to attach "floating" comments in the source. >> Does a comment *before* a function apply to the next function or not? >> >> 6) We need some "injection" API to inject code, meta-data, examples >> and documentations into a data base. >> >> For example inject:code("foo.erl") should inject a load of key/value >> pairs into a data base, with something like the following keys >> >> {text, Mod,Func,Arity} => the source code text >> {spec, Mod, Func, Arity} => the spec >> {doc, Mod,Func,Arity} => the documentation >> {examples,Mod,Func,Arity} = [Examples] >> >> The entities in the database should be sufficient to reconstruct the >> original text, and perform various analysis of the functions. >> >> I think *most* of the problems involved are due to the difficulty of >> extracting information from the source files and editing this when it is >> wrong. >> >> I'm currently trying to do parts of this. >> >> A "relatively simple" program should be able to (for a given function) >> >> - find the exact source text >> - find all old versions >> - find the specs and types referred to >> - find the documentation >> - find the test cases >> >> Doing so involves analysing the erlang sources the XML sources and the >> test cases, and involves a deal of guess work. >> >> All this must be done on a moving target and should not break the >> existing system. >> >> I suspect that the code to accurately manipulate the code and >> documentation have been has been written several times in different >> projects (for example >> the wrangler, and the Eclipse interface) both need to manipulate the >> source >> in various ways. >> >> >> >> >> On Mon, Sep 26, 2016 at 6:41 PM, wrote: >> > Joe, >> > >> > You've said so well what I've been trying to harp on. >> > >> > My most recent timesink has been trying to understand xmerl >> sufficiently well to pull book data out of several different book APIs. >> Dave Thomas's 2007 tutorial has been a big help, but the black holes in my >> understanding still significantly impede my progress. So far I've spent >> maybe 10 to 15 hours trying to scope it out. I can get much of what I need >> from Amazon's APIs, but I need a redundant source. The Library of Congress >> API completely eludes me; I get a little further with ISBNdb, but still not >> far enough. >> > >> > Given discussion on the documentation thread to date, it seems to me >> that there are four issues at stake: >> > >> > 1) Content deficiencies >> > 2) Formatting issues >> > 3) Lack of consensus of what we, as a community, want >> > 4) How we move forward toward comprehensive improvement of >> documentation. >> > >> > Lukas Larsson's most recent post makes a good point. >> > >> > Bruce Yinhe tells me in a private post that his group is about to hire >> one person on a part-time basis to work on documentation improvements. >> > >> > I've lost it in the thread, but as I recall we had some promising >> interest in documentation improvements from an Erricson employee. >> > >> > It would be great if we could begin to rally around these comments and >> find some kind of convergence toward progress. >> > >> > My take is to break the large task down into small chunks, bring the >> intelligence and resources of the community to bear on one specific issue >> at a time and, and get it done. >> >> I think many (most) of the problems arise because what we are ultimately >> doing is changing the content of a file at some place. >> >> Fixing a typo/bug involves >> >> 1- finding the appropriate file >> 2 - changing the file at the appropriate place >> 3 - updating the file (somehow) >> 4 - generating the downstream documents that depend upon the file >> >> All these steps are difficult >> >> We can imagine a simpler way: >> >> Suppose a file is a sequence of paragraphs. Each paragraph >> has a GUId >> >> In (say) HTML >> >>

>> This is my paragarph ... >>

>> >> If I want to update the paragraphs I just send a message >> >> {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" >> "the new content"} >> >> to some server - this should be checked (manually) and then >> if approved used to update everything. >> >> In other threads I have argued that *everything* should be in a global >> database with a huge DHT tracking where things are. >> >> A key to "changing things" is "naming things" and "finding things" >> >> yes another (even simpler) alternative is to have a message >> >> {change,SHA,NewText} >> >> Meaning "change the paragraph with sha1 checksum to " >> >> Implementing this is easy - BUT all paragraphs with the same SHA >> would be changed - which might not be what we want. >> >> I have (incidentally) experimented with this - tagging all paragraphs >> with their SHAs and sticking the results in a database. >> >> >> make a server that accepts messages of the form >> >> {change, , } >> >> The server finds a paragraph with sha1 checksum and changes >> it to - it changes the appropriate file in a GIT archive >> does all the /add/commit/push magic and the job is done. >> >> (I think I'll implement this for fun :-) >> >> >> >> > >> > I don't have the technical chops, but I'll gladly work with you or >> anyone else to address content issues on a module-by-module basis. I can >> ask Micky-the_Dunce questions and, perhaps, help clarify language. It would >> be great if you could help clarify intent and application issues. >> > >> > All the best, >> > >> > Lloyd >> > >> > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: "Joe Armstrong" >> > Sent: Monday, September 26, 2016 6:42am >> > To: "Lukas Larsson" >> > Cc: "Lloyd R. Prentice" , " >> erlang-questions@REDACTED" >> > Subject: Re: [erlang-questions] Erlang documentation -- a modest >> proposal >> > >> > I think what I miss most are *examples* >> > >> > I've just been reading the edoc manual pages for a program >> > called (name changed to avoid embarrassment) >> > >> > The functions are well documented - they types are well documented >> > but I haven't a clue about which ORDER to call the functions >> > >> > Imagine a file system. >> > >> > We *document* the open, read, write, and close functions >> > but we don't say you have to open the file before we read it. >> > We dont say when we're done we have to close the file. >> > >> > We don't say this because it is *obvious* >> > >> > But for the module glonk, which exports, zizzle, taddle, glonk and plonk >> > it is NOT obvious. Yes sure you all know you have to call glonk 3 times >> > before calling plonk - but I don't know. >> > >> > Thats why we need examples. >> > >> > Often I search for a tutorial and find a ten line blog posting that >> > actually shows me how to use a library - this gets me started. >> > >> > very short unit tests - placed inline are *very* useful >> > >> > for example: >> > >> > "321" = lists:reverse("123") >> > >> > The unit test *are* the examples - what we don't have is software that >> > parses the code, parses the documentation, parses the unit test >> > and munges all together into a form that is convenient to read. >> > >> > I'm actually trying to write something like this now - hence my wails >> > of anguish over css. >> > >> > Wish me luck >> > >> > /Joe >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson >> wrote: >> >> Hello, >> >> >> >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice < >> lloyd@REDACTED> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> To date, this thread has generated quite a few worthwhile insights and >> >>> ideas. My fear is that they will be deep-sixed into the archive. On >> the >> >>> other hand, major revision is a daunting task and unlikely to happen. >> >>> >> >>> But maybe we can focus on specific issues and make iterative headway. >> >>> >> >>> Fewer than half of the functions in the lists library, for instance, >> have >> >>> code examples. Suppose over the span of one week we were collectively >> focus >> >>> on generating at least two code examples for each function in one >> library. >> >>> >> >>> At the end of the week we could organize the submissions and vote on >> best >> >>> candidates for inclusion in the docs. That done, we can pick another >> module. >> >>> >> >>> Thus, with not much effort from any one individual, a small posse of >> >>> volunteer Erlang wizards could make short work of deficiencies in the >> docs. >> >>> >> >>> Anyway, it's an idea. >> >>> >> >>> All the best, >> >>> >> >>> LRP >> >>> >> >> >> >> I think that it is great to see everyone talking about wanting to >> improve >> >> the documentation. The contributions to the Erlang/OTP project that I >> value >> >> that most are documentation changes that make the intention clearer, or >> >> explains some corner case somewhere which the docs did not initially >> >> mention. >> >> >> >> Unfortunately, once one has figured out how a function works there >> seems to >> >> be very little incentive to make the docs clearer. I would estimate >> that >> >> about every 20th pull request we get is a documentation fix, and more >> than >> >> half of those are fixes of speling misstakes (which are great!). >> >> >> >> I've just come back from about two weeks of vacation and this >> discussion has >> >> resulted in roughly 0 pull requests for changes in the documentation. >> Would >> >> it be possible to steer this discussion into doing something instead of >> >> talking about doing something? Yes the technology/layout is not >> perfect, but >> >> as Lo?c said, it is the content that matters the most. >> >> >> >> Lukas >> >> // my own oppinions >> >> >> >> _______________________________________________ >> >> 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 kenneth@REDACTED Tue Sep 27 13:57:03 2016 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 27 Sep 2016 13:57:03 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: On Tue, Sep 27, 2016 at 1:03 PM, Martin Karlsson < martin@REDACTED> wrote: > Hi guys, > > > Interesting would be to know how many % of the users that actually are > using the man and pdf pages. > The man pages is the erlang documentation I use the most. In fact I Iike > them so much I had to reply to this thread to reduce the risk of them going > away :). They are much quicker than anything if you have a console based > work-flow. I even miss the man pages for all external libraries. I would > love if there was a common erlang documentation system making it easy for > external libraries to produce the same style and type of documentation as > the official documentation. > erl_docgen included in OTP is such a toll with which you can build documentation in the same style as the official one. Of course the documentation for erl_docgen itself could be improved as well:) But we are using it for the OTP documentation and the intention has always been that it can be used for the users applications as well. > I am not overly attached to a documentation system but there are a few > that does conversion to lots of formats with good quality, for example > sphinx which can generate html, latex, man pages, epub among others. > > A final comment regarding html generated documentation. Please don't rely > on javascript for more than enhancing the experience. I see lots of modern > html documentation which doesn't display all data (for example code > examples) or can't do navigation without javascript. > > Cheers, > Martin > > /Kenneth Erlang/OTP , Ericsson > > > > _______________________________________________ > 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 Tue Sep 27 14:06:30 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 27 Sep 2016 14:06:30 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> On 09/27/2016 01:13 PM, Kenneth Lundin wrote: > On Tue, Sep 27, 2016 at 11:46 AM, Joe Armstrong > wrote: > > Re: HTML > > I'd very much like to mock up a "nice" HTML display of the functions > in a module. > > > Have you looked at the Elixir doc for > example http://elixir-lang.org/docs/stable/elixir/Kernel.html? > I think the layout and function is quite good and the handling of css > and javascript is from what I can understand > handled nicely. > > For an application and modules they present pretty much the same as we > do today. > For sure the Elixir community have more cometence around html, css, > javascript than at least we on the OTP team have. I have no doubt they are better at HTML, CSS and JS, but they are not good at layout and styling IMO. The lack of indentation alone makes the Elixir documentation unreadable. Where do the functions start and end? This is much easier to figure out in the Erlang documentation. The huge vertical spacing everywhere makes it so that only about one function and a half gets displayed on my screen at a time for equivalent amount of information. The Erlang documentation has the double, 3 or 4 functions. For some reason all the specs and code examples have a bottom scrollbar here even when no scrolling can be done. And in case you wonder, it's also unreadable from lynx. This time, function names and code examples are indistinguishable. The list of functions at the top is not very useful overall; the list of functions on the left is better but in the case of Elixir when I click "Functions" it scrolls the page for some reason; if I wanted to stay where I was and just take a quick look if a function exists, there goes my browsing. It also breaks the back/forward buttons for me (bad!). Not to mention it's not clear that you can expand it. The search result page also gets on top of the documentation you are currently reading. Impractical. The Elixir layout still needs a *lot* of work to be really usable. Not to say the Erlang documentation is "the best", but what it needs the most is a few tweaks (make it easy to reach every part of the documentation from http://erlang.org/doc/) and more content. It's already very good, in all its output formats. This would be a huge step backward. I also have some concerns with the main Elixir site; the font and font size make it hard to read. At least they got the font right in the function reference. (If you worked on the Elixir documentation don't take this personally. I have the same amount of criticism over my own, if not more.) -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From dmytro.lytovchenko@REDACTED Tue Sep 27 14:12:15 2016 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Tue, 27 Sep 2016 14:12:15 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: Just a thought. Here in the discussion, has anyone considered converting existing docs to the input format of some popular documenting tool? I can imagine that producing Restructured Text for Sphinx is doable, output is beautiful, static html that can be themed and no problems with code snippets either. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.behnke@REDACTED Tue Sep 27 14:19:24 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Tue, 27 Sep 2016 14:19:24 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <21d16e06-6b49-ba73-cb6f-517e16b131c5@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <9b90c91a-2cda-3b24-9427-061b5ceca21d@informatik.haw-hamburg.de> <21d16e06-6b49-ba73-cb6f-517e16b131c5@cs.otago.ac.nz> Message-ID: <114be6a5-fa1c-2dcd-32f4-2921e6f2b8e4@informatik.haw-hamburg.de> Am 26.09.2016 um 23:49 schrieb Richard A. O'Keefe: > > > On 26/09/16 6:40 PM, Lutz Behnke wrote: >>> (For maintenance purposes, I would like to track code >>> changes separately from documentation changes, but that's >>> another issue.) >> >> How do you keep track of source changes making it into doc changes? > > I don't understand the question. If you are talking about a change > to the source code that has a corresponding (but necessarily > different) change to the documentation, then they form a single > commit with a common MR or other identifier (if such are used). Yes, if the documentation is done properly and the programmer also has the necessary skills as a writer. I have worse eperience that led many project to the state you describe below. >> >> Possibly, my level of expectation is so low, that I find almost any >> published doxygem better that having to pick apart the source drop. >> >> If the user doesn't know what he or she needs yet, then reference docs >> (which I was specifically targetting) are not the right piece of the >> docs for them. > > I was thinking of a number of fairly popular open source projects > where there was a sketchy tutorial and then a Doxygen puke (with > many of the functions uncommented, just automatic headers) *instead* > of documentation. That is _no_docs_ and should not count ;-) But Erlang currently is far beyond that state. > > Actually, if you look at source code, there are often cues to be had > from the words inside the functions. But it is not presented separately and with a minimal barrier of entry, have some amount of pretty pringint. Thus pure source code is the method of last choice for projects that fall into the _no_docs_ category. > > I guess it depends on what you mean by "published Doxygen". > I was meaning "so-called documentation made available to people outside > the project generated using Doxygen." > > BTW: I am painfully aware that my own documentation skills leave much > to be desired. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5006 bytes Desc: S/MIME Cryptographic Signature URL: From dmytro.lytovchenko@REDACTED Tue Sep 27 14:59:19 2016 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Tue, 27 Sep 2016 12:59:19 +0000 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: I can explain further. This is a low hanging fruit, to produce RST (which is like Markdown but better) from input files and feed it to a production grade documentation tool (Sphinx is what used to build docs for Python and million smaller projects http://www.sphinx-doc.org/en/stable/examples.html ) Using this RST it is able to produce static nice looking HTML with search bar, cross references (to functions, to types, to chapters/sections etc), code snippets, links, URL references and images, all that sort of thing based only on RST input. Each page also contains link to Github page source (does this ring a bell?) Along with HTML a PDF version can be produced. This seems to cover many of Kenneth Lundin's concerns and requirements to a better documentation. Again, this is a low hanging fruit. Just produce RST from Edoc and see if the team and community like it. I could possibly try and produce a POC. tis 27 sep. 2016 kl 14:12 skrev Dmytro Lytovchenko < dmytro.lytovchenko@REDACTED>: > Just a thought. > Here in the discussion, has anyone considered converting existing docs to > the input format of some popular documenting tool? I can imagine that > producing Restructured Text for Sphinx is doable, output is beautiful, > static html that can be themed and no problems with code snippets either. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Tue Sep 27 15:42:47 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 27 Sep 2016 15:42:47 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: Hi, I'm not sure which message to answer to best. Assuming that converting the XML sources to something else isn't going to be the first thing that will happen, I'd like to suggest a HTML structure that is much better than the existing one and is following the XML almost faithfully. All XML tags become sections or divs, with the respective tag as class name. The "module" section wraps everything instead of being a header. Like I said before, this structure can also be easily parsed instead of the XML for extracting the documentation, if the sources aren't available. See an example at https://gist.github.com/vladdu/ 8a70874c492233dcce01f353567d1281. This structure can be easily displayed almost however we want with CSS, and I will try to submit a couple of suggestions. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Sep 27 18:45:09 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 27 Sep 2016 12:45:09 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: <1474994709.572832494@apps.rackspace.com> Hi Kenneth, Thanks, I'll take a look. I need to dig deeper, but so far I haven't found schemas. I've been working through these sources: http://docs.aws.amazon.com/AWSECommerceService/latest/DG/EX_LookupbyISBN.html --- I can get the book facts I need here via xmerl, but would also like a redundant source. So far I haven't been able to locate a schema. https://www.loc.gov/z3950/lcserver.html#serv --- info overload -- still trying to figure it out http://isbndb.com/api/v2/docs -- can get partial info here via xmerl, but need to do some inconvenient post processing. Thanks again for the suggestion. Lloyd -----Original Message----- From: "Kenneth Lakin" Sent: Monday, September 26, 2016 6:58pm To: erlang-questions@REDACTED Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions On 09/26/2016 09:41 AM, lloyd@REDACTED wrote: > My most recent timesink has been trying to understand xmerl... If you have an XML schema file, erlsom can be run in "data binder" mode which will create a nice Erlang record out of a well-formed XML document: https://github.com/willemdj/erlsom As part of this mode of operation, erlsom can also process the XML schema file and create a hrl file containing the record definition. I found this _much_ easier to work with than what xmerl offers. From rexxe98@REDACTED Tue Sep 27 18:45:12 2016 From: rexxe98@REDACTED (Andrew Berman) Date: Tue, 27 Sep 2016 16:45:12 +0000 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: I'm sure some of you will disagree, but I've always found the Java SE docs to be easy to use and useful: https://docs.oracle.com/javase/8/docs/api/ Couple reasons why: 1. The class list on the left doesn't move when I scroll on the right. I'd say this is a must with any documentation. Erlang docs already do this, but I'd like to just point out how essential it is. 2. When you click a class, you get a nice, detailed class description at the top, then you get a summary of all the methods. I think this summary is something that would be very useful for Erlang docs. Most of the time I don't need to see all the details of an Erlang function, I just need to know of its existence, briefly what it does, and what it takes in and spits out. This sort of summary is great for that. And when I do need more in-depth info, I can click the function name and it takes me right to it. 3. I like how everything is clearly sectioned off. Each method in the docs has its own box, each section is clearly defined, etc. This goes to Lo?c's point of indentation. By sectioning off the methods, it makes things very readable. I can scroll down and immediately know what method I'm on and what the text below it refers to no matter where I am in the doc. 4. Everything is hyperlinked. If there is a class referenced, it's hyperlinked so I can go and visit that class very easily. Again, Erlang docs pretty much do this as well, but I'd imagine there are places where it can be expanded. --Andrew On Tue, Sep 27, 2016 at 5:06 AM Lo?c Hoguin wrote: > On 09/27/2016 01:13 PM, Kenneth Lundin wrote: > > On Tue, Sep 27, 2016 at 11:46 AM, Joe Armstrong > > wrote: > > > > Re: HTML > > > > I'd very much like to mock up a "nice" HTML display of the functions > > in a module. > > > > > > Have you looked at the Elixir doc for > > example http://elixir-lang.org/docs/stable/elixir/Kernel.html? > > I think the layout and function is quite good and the handling of css > > and javascript is from what I can understand > > handled nicely. > > > > For an application and modules they present pretty much the same as we > > do today. > > For sure the Elixir community have more cometence around html, css, > > javascript than at least we on the OTP team have. > > I have no doubt they are better at HTML, CSS and JS, but they are not > good at layout and styling IMO. > > The lack of indentation alone makes the Elixir documentation unreadable. > Where do the functions start and end? This is much easier to figure out > in the Erlang documentation. > > The huge vertical spacing everywhere makes it so that only about one > function and a half gets displayed on my screen at a time for equivalent > amount of information. The Erlang documentation has the double, 3 or 4 > functions. > > For some reason all the specs and code examples have a bottom scrollbar > here even when no scrolling can be done. > > And in case you wonder, it's also unreadable from lynx. This time, > function names and code examples are indistinguishable. > > The list of functions at the top is not very useful overall; the list of > functions on the left is better but in the case of Elixir when I click > "Functions" it scrolls the page for some reason; if I wanted to stay > where I was and just take a quick look if a function exists, there goes > my browsing. It also breaks the back/forward buttons for me (bad!). Not > to mention it's not clear that you can expand it. > > The search result page also gets on top of the documentation you are > currently reading. Impractical. > > The Elixir layout still needs a *lot* of work to be really usable. Not > to say the Erlang documentation is "the best", but what it needs the > most is a few tweaks (make it easy to reach every part of the > documentation from http://erlang.org/doc/) and more content. It's > already very good, in all its output formats. This would be a huge step > backward. > > I also have some concerns with the main Elixir site; the font and font > size make it hard to read. At least they got the font right in the > function reference. > > (If you worked on the Elixir documentation don't take this personally. I > have the same amount of criticism over my own, if not more.) > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Sep 27 18:48:14 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 27 Sep 2016 12:48:14 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: <1474994894.878612554@apps.rackspace.com> > So here's an idea .. we (or I in this case) write a 'best of' document > The best of should have: > > - the *best* modules (which modules do I use most) > - the *best functions* (which functions (per module) do I use most) +1 LRP -----Original Message----- From: "Joe Armstrong" Sent: Tuesday, September 27, 2016 2:26am To: "Lukas Larsson" Cc: "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal On Mon, Sep 26, 2016 at 10:51 PM, Lukas Larsson wrote: > Hello Joe, > > What you are talking about is about lowering the cost of entry when doing > documentation updates. This is a great effort and one which we should really > pursue, but as you say it is a lot of work. Is there really a *need* for > that to be in place first? Can't there be lots of smaller parallel efforts > (we as Erlang programmers should be familiar with the concept) that improve > the content at the same time? > > Since I'm preaching action rather than discussions, it would hypocritical of > me to not do anything so I've submitted a PR with a documentation change > that I believe will make binary_to_term/1 a little clearer for anyone > wondering how to use it for the first time: > https://github.com/erlang/otp/pull/1181 Thank you Lukas. This patch made my head explode. How can an example of binary_to_term NOT mention term_to_binary? When I lecture I say that that the PAIR of functions term_to_binary and binary_to_term are FANTASTIC - and I hang my head in shame if having read one of my books this fact was not made abundantly clear. NOT ALL FUNCTIONS ARE EQUALLY IMPORTANT The Erlang manual page is *gigantic* I for one, certainly don't know all the functions in the Erlang manual page - I also only use a handful of functions in file, dict and lists It occurs to me that I probably only use 5% of the functions in file.erl 8% of the functions in dict.erl and so on. I don't know the numbers here, so I'm guessing. Since I can manage perfectly well knowing only 5% of the functions in file, then I'd like to ask - do we need all the other functions? Answer: Yes - on rare occasions I need a specific functionality, so I have search the manual page and read the text very carefully - do beginners know which functions in (say file) are what I consider to be the important ones? Answer: No - how could they So here's an idea .. we (or I in this case) write a 'best of' document The best of should have: - the *best* modules (which modules do I use most) - the *best functions* (which functions (per module) do I use most) I think I "know" that answers without analysis. So, for example, in dict.erl I'd hazard I guess that I use new/1, store/3, find/2, from_list/1, to_list/2. For me these functions are in my 'working set' of functions. ie the functions that I use a lot and are in my memory. It seems to me that it might be beneficial to make some special 'best of' documentation that only documents the essential core functions in the libraries. I'd also like to compare my 'best of' lists with other programmers on this list. What are Richard and Lukas favorite functions? I can easily write a program to statically analyse my code to pull out these figures. I think it would be a good idea if instead of throwing 10MBytes of documentation at beginners we should aim to tell them what the essential set of modules is, and what the essential functions are in those modules and how they should be used. As for advanced users - the documentation we have is all we have - and gradual improvement is needed. Cheers /Joe > > Lukas > > On Mon, Sep 26, 2016 at 10:03 PM, Joe Armstrong wrote: >> >> Regarding the documentation - there is a step0 that needs to be done >> *before* attacking the document improvement problem. >> >> The following things are needed (I my opinion) >> >> 1) The number of DTDs in the documentation should be reduced to ONE >> there are currently 26 these are in >> otp_src_/lib/erl_docgen/priv/dtd >> >> 2) tags that are used infrequently should be removed and the source XML >> corrected. Some tags are virtually *never* used. >> >> 3) All XML files should validate with the new DTD >> >> These steps need quite a lot of work ... >> >> 4) The Erlang parser should be changed to exactly >> reproduce the source. >> Right now the parse tree of correct erlang has all the comments >> and white space removed. I'd suggest attaching the comments to the >> next following token (for example {atom,Line,theAtom} should become >> {atom, Line, theAtom, "the preceding comments and white space"} >> It should be possible to *exactly* reconstruct the input from the parse >> tree. >> >> >> >> >> >> >> >> 5) We should decide how to attach "floating" comments in the source. >> Does a comment *before* a function apply to the next function or not? >> >> 6) We need some "injection" API to inject code, meta-data, examples >> and documentations into a data base. >> >> For example inject:code("foo.erl") should inject a load of key/value >> pairs into a data base, with something like the following keys >> >> {text, Mod,Func,Arity} => the source code text >> {spec, Mod, Func, Arity} => the spec >> {doc, Mod,Func,Arity} => the documentation >> {examples,Mod,Func,Arity} = [Examples] >> >> The entities in the database should be sufficient to reconstruct the >> original text, and perform various analysis of the functions. >> >> I think *most* of the problems involved are due to the difficulty of >> extracting information from the source files and editing this when it is >> wrong. >> >> I'm currently trying to do parts of this. >> >> A "relatively simple" program should be able to (for a given function) >> >> - find the exact source text >> - find all old versions >> - find the specs and types referred to >> - find the documentation >> - find the test cases >> >> Doing so involves analysing the erlang sources the XML sources and the >> test cases, and involves a deal of guess work. >> >> All this must be done on a moving target and should not break the >> existing system. >> >> I suspect that the code to accurately manipulate the code and >> documentation have been has been written several times in different >> projects (for example >> the wrangler, and the Eclipse interface) both need to manipulate the >> source >> in various ways. >> >> >> >> >> On Mon, Sep 26, 2016 at 6:41 PM, wrote: >> > Joe, >> > >> > You've said so well what I've been trying to harp on. >> > >> > My most recent timesink has been trying to understand xmerl sufficiently >> > well to pull book data out of several different book APIs. Dave Thomas's >> > 2007 tutorial has been a big help, but the black holes in my understanding >> > still significantly impede my progress. So far I've spent maybe 10 to 15 >> > hours trying to scope it out. I can get much of what I need from Amazon's >> > APIs, but I need a redundant source. The Library of Congress API completely >> > eludes me; I get a little further with ISBNdb, but still not far enough. >> > >> > Given discussion on the documentation thread to date, it seems to me >> > that there are four issues at stake: >> > >> > 1) Content deficiencies >> > 2) Formatting issues >> > 3) Lack of consensus of what we, as a community, want >> > 4) How we move forward toward comprehensive improvement of >> > documentation. >> > >> > Lukas Larsson's most recent post makes a good point. >> > >> > Bruce Yinhe tells me in a private post that his group is about to hire >> > one person on a part-time basis to work on documentation improvements. >> > >> > I've lost it in the thread, but as I recall we had some promising >> > interest in documentation improvements from an Erricson employee. >> > >> > It would be great if we could begin to rally around these comments and >> > find some kind of convergence toward progress. >> > >> > My take is to break the large task down into small chunks, bring the >> > intelligence and resources of the community to bear on one specific issue at >> > a time and, and get it done. >> >> I think many (most) of the problems arise because what we are ultimately >> doing is changing the content of a file at some place. >> >> Fixing a typo/bug involves >> >> 1- finding the appropriate file >> 2 - changing the file at the appropriate place >> 3 - updating the file (somehow) >> 4 - generating the downstream documents that depend upon the file >> >> All these steps are difficult >> >> We can imagine a simpler way: >> >> Suppose a file is a sequence of paragraphs. Each paragraph >> has a GUId >> >> In (say) HTML >> >>

>> This is my paragarph ... >>

>> >> If I want to update the paragraphs I just send a message >> >> {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" >> "the new content"} >> >> to some server - this should be checked (manually) and then >> if approved used to update everything. >> >> In other threads I have argued that *everything* should be in a global >> database with a huge DHT tracking where things are. >> >> A key to "changing things" is "naming things" and "finding things" >> >> yes another (even simpler) alternative is to have a message >> >> {change,SHA,NewText} >> >> Meaning "change the paragraph with sha1 checksum to " >> >> Implementing this is easy - BUT all paragraphs with the same SHA >> would be changed - which might not be what we want. >> >> I have (incidentally) experimented with this - tagging all paragraphs >> with their SHAs and sticking the results in a database. >> >> >> make a server that accepts messages of the form >> >> {change, , } >> >> The server finds a paragraph with sha1 checksum and changes >> it to - it changes the appropriate file in a GIT archive >> does all the /add/commit/push magic and the job is done. >> >> (I think I'll implement this for fun :-) >> >> >> >> > >> > I don't have the technical chops, but I'll gladly work with you or >> > anyone else to address content issues on a module-by-module basis. I can ask >> > Micky-the_Dunce questions and, perhaps, help clarify language. It would be >> > great if you could help clarify intent and application issues. >> > >> > All the best, >> > >> > Lloyd >> > >> > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: "Joe Armstrong" >> > Sent: Monday, September 26, 2016 6:42am >> > To: "Lukas Larsson" >> > Cc: "Lloyd R. Prentice" , >> > "erlang-questions@REDACTED" >> > Subject: Re: [erlang-questions] Erlang documentation -- a modest >> > proposal >> > >> > I think what I miss most are *examples* >> > >> > I've just been reading the edoc manual pages for a program >> > called (name changed to avoid embarrassment) >> > >> > The functions are well documented - they types are well documented >> > but I haven't a clue about which ORDER to call the functions >> > >> > Imagine a file system. >> > >> > We *document* the open, read, write, and close functions >> > but we don't say you have to open the file before we read it. >> > We dont say when we're done we have to close the file. >> > >> > We don't say this because it is *obvious* >> > >> > But for the module glonk, which exports, zizzle, taddle, glonk and plonk >> > it is NOT obvious. Yes sure you all know you have to call glonk 3 times >> > before calling plonk - but I don't know. >> > >> > Thats why we need examples. >> > >> > Often I search for a tutorial and find a ten line blog posting that >> > actually shows me how to use a library - this gets me started. >> > >> > very short unit tests - placed inline are *very* useful >> > >> > for example: >> > >> > "321" = lists:reverse("123") >> > >> > The unit test *are* the examples - what we don't have is software that >> > parses the code, parses the documentation, parses the unit test >> > and munges all together into a form that is convenient to read. >> > >> > I'm actually trying to write something like this now - hence my wails >> > of anguish over css. >> > >> > Wish me luck >> > >> > /Joe >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson >> > wrote: >> >> Hello, >> >> >> >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice >> >> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> To date, this thread has generated quite a few worthwhile insights and >> >>> ideas. My fear is that they will be deep-sixed into the archive. On >> >>> the >> >>> other hand, major revision is a daunting task and unlikely to happen. >> >>> >> >>> But maybe we can focus on specific issues and make iterative headway. >> >>> >> >>> Fewer than half of the functions in the lists library, for instance, >> >>> have >> >>> code examples. Suppose over the span of one week we were collectively >> >>> focus >> >>> on generating at least two code examples for each function in one >> >>> library. >> >>> >> >>> At the end of the week we could organize the submissions and vote on >> >>> best >> >>> candidates for inclusion in the docs. That done, we can pick another >> >>> module. >> >>> >> >>> Thus, with not much effort from any one individual, a small posse of >> >>> volunteer Erlang wizards could make short work of deficiencies in the >> >>> docs. >> >>> >> >>> Anyway, it's an idea. >> >>> >> >>> All the best, >> >>> >> >>> LRP >> >>> >> >> >> >> I think that it is great to see everyone talking about wanting to >> >> improve >> >> the documentation. The contributions to the Erlang/OTP project that I >> >> value >> >> that most are documentation changes that make the intention clearer, or >> >> explains some corner case somewhere which the docs did not initially >> >> mention. >> >> >> >> Unfortunately, once one has figured out how a function works there >> >> seems to >> >> be very little incentive to make the docs clearer. I would estimate >> >> that >> >> about every 20th pull request we get is a documentation fix, and more >> >> than >> >> half of those are fixes of speling misstakes (which are great!). >> >> >> >> I've just come back from about two weeks of vacation and this >> >> discussion has >> >> resulted in roughly 0 pull requests for changes in the documentation. >> >> Would >> >> it be possible to steer this discussion into doing something instead of >> >> talking about doing something? Yes the technology/layout is not >> >> perfect, but >> >> as Lo?c said, it is the content that matters the most. >> >> >> >> Lukas >> >> // my own oppinions >> >> >> >> _______________________________________________ >> >> 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 lloyd@REDACTED Tue Sep 27 18:56:01 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 27 Sep 2016 12:56:01 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <1474995361.993230350@apps.rackspace.com> Much applause. Some coordination with Erlang Central might generate valuable synergy. There hasn't been much mention of tutorials. I agree that they shouldn't be in reference docs. But from my perspective as one striving to learn from books and the net, they are invaluable. Ideally they are simple projects that result in a useful tool or application. LRP -----Original Message----- From: "Kenneth Lundin" Sent: Tuesday, September 27, 2016 3:44am To: "Lukas Larsson" Cc: "Lloyd R. Prentice" , "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal Hi, I have followed this thread with interest since there are many good suggestions and ideas. As Lukas mentioned it would be good if we could agree on some action(s) in which the community could contribute. First some info about what we (The OTP team at Ericsson and the Industrial Erlang User Group) plan to do. - Nicer , better HTML layout of the docs. The Elixir look layout looks quite nice and since it is overlapping communities it could be good to have the same or similar layout. The HTML, CSS, Javascript setup seems quite well thought. Take a look at http://elixir-lang.org/docs/stable/elixir/Kernel.html# full-list. If you have suggestions regarding the html layout they are welcome. In that case it would be nice with a small example showing for example the beginning of the lists module and a few functions. Note this step does not require changes of the doc source which is XML it is just a matter of tooling. Translating the current XML to html (when you know what html you want). - Making it easier to contribute with documentation improvements. One simple step can be to add a link to the doc source at github from the generated html page. Another to write a short guide on how to contribute to the documentation. - Having technical writers going through the documentation in order to correct language and consistency. This is ongoing. - Making the search in documentation on www.erlang.org more visible. You can search on application, modules, functions. - Validate the current doc sources with XMLLINT to assure that we are following our own DTDs. This is almost done and with this in place it is easy to translate the doc sources to some other format like a simpler XML dtd (or XSD), asciidoc or even markdown. Note that there is only one common source for the documentation and it is in XML with a few exceptions. Each application has a doc/src directory where its documentation source files are. There is module references for the modules with public APIs and a User Guide (mostly). From this thread I think the following are the most interesting suggestions: Examples in the doc ------------------------------ I agree that we need more examples in the documentation. It would for example be good to have a short example for almost every function in a module. This can be done in various ways. Either embed the example in the text or have a separate example file in parallell with the text. In both cases I would like to have the possibility to automatically check the syntax and execution of the example during the build documentation build process. If not checked we will soon have a number of non working examples. The presentation view of examples is just a tooling question independent on the actual source for the examples. The first thing is to create the source for examples and what format we should use for this (same for all modules of course). Man pages or not? ------------------------- I understand that some of you are using the man pages. But the question is why are you using them? Is it because it is easy to type "man lists" or "erl -man lists"? What if "erl -man lists" pops up in a web-browser window of you choice instead?, Note that it is exactly the same information shown in the lists.html and in the man page for lists. PDF or not? ------------------ I think it is rather unusual that the PDF pages we generate to day are used compared to the HTML variant. Correct me if I am wrong. Perhaps Epub or something else would be more useful. I suppose the html variant could also support printing and or saving as pdf without to much effort from our side. More User Guide oriented text or cook books. --------------------------------------------------------------- This is very valuable but does not have to be part of the Erlang/OTP release. Could be hosted on a web-site like Erlang Central (and there is already material like this there I think). I have probably forgotten lots of things that I should have mentioned and commented , but this is it for now. /Kenneth, Erlang/OTP , Ericsson From lloyd@REDACTED Tue Sep 27 18:58:46 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 27 Sep 2016 12:58:46 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: <1474995526.635215018@apps.rackspace.com> I haven't used it yet, but Pandoc looks promising. http://pandoc.org/ Best to all, LRP -----Original Message----- From: "Kenneth Lundin" Sent: Tuesday, September 27, 2016 5:08am To: "Lo?c Hoguin" Cc: "Lukas Larsson" , "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions On Tue, Sep 27, 2016 at 10:39 AM, Lo?c Hoguin wrote: > On 09/27/2016 09:44 AM, Kenneth Lundin wrote: > >> Man pages or not? >> ------------------------- >> >> I understand that some of you are using the man pages. But the question >> is why are you using them? >> Is it because it is easy to type "man lists" or "erl -man lists"? What >> if "erl -man lists" pops up in a web-browser window of you choice >> instead?, Note that it is exactly the same information shown in the >> lists.html and in the man page for lists. >> > > It would be terrible for many reasons: > > * lack of search; command line manual search is very useful (man -k and > others) > I don't think the search has to be worse in the html form, it depends on how we do it. > * man pages are readable in 80x24 windows; browsers aren't > Have you tried lynx? a text based web-browser I think our html pages looks quite good in that one. > * opening in a separate window is awkward; currently I need to do this to > have what I need: Menu key (opens a terminal), "man lists"; with what you > suggest I need at least a couple more steps > * if i want to have the manual side by side with the code, I need a > different browser or browser window; I already fight with Dialyzer because > it runs out of memory on some modules, I don't need the waste browsers add > on top of that > > Also note that in the absence of man pages, I'd look first into 'info' or > PDF formats before I consider local HTML. HTML is just not practical for > manuals. > > I'm also wondering why the intent to remove man/PDF formats. They're > already working, it doesn't sound like they would need much maintenance to > be kept, they have users, so why consider removing them? It doesn't make > much sense to me. html, pdf and man are 3 different backends for generating documentation of course it will cost more to maintain and develop 3 backends instead of 1 or 2. This is especially true if new features are introduced in the document source format or if we even change the format completely. But this is just a possibility (to remove formats that are not so much used) , no decision is taken. Interesting would be to know how many % of the users that actually are using the man and pdf pages. /Kenneth, Erlang/OTP Ericsson > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From lloyd@REDACTED Tue Sep 27 19:05:23 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 27 Sep 2016 13:05:23 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <1474995923.96225627@apps.rackspace.com> Hello, In the spirit of eating our own dog food, Erlang Nitrogen provides many nice functions (elements and actions) for creating dynamic web pages, including such things as clickable folds and hover pop ups. It's easy to get started. Jesse Gumm and I have trying in the small spaces of busy lives to produce a how-to book. Still very rough but more to come "real soon now." You can download work-in-progress for free: http://builditwith.com/nitrogen Best, LRP -----Original Message----- From: "Joe Armstrong" Sent: Tuesday, September 27, 2016 5:46am To: "Kenneth Lundin" Cc: "Lukas Larsson" , "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal Re: HTML I'd very much like to mock up a "nice" HTML display of the functions in a module. What I'd like is for most of the information to be initially hidden and to be made available through clickable folds or hover popups. Doing this involves a few different problems: 1) - extracting the necessary information to be displayed from the XML or erlang sources 2) - turning 1) into HTML markup 3) - adding some CSS/JS magic to create hover popups/folds and so on. I have a good idea how to do 1) - step 2) is easy if I know what markup to produce. I'm rubbish at step 3) I guess there must be someone reading this list who is skilled in the art of CSS/JS and could suggest a suitable markup. Being a tad fussy about these things I wonder if it's possible to get a pretty display *without* including 200KB of JS libraries and CSS stuff. If some kind people could mockup a a few pages with dummy markup it might help move things along Cheers /Joe On Tue, Sep 27, 2016 at 9:44 AM, Kenneth Lundin wrote: > Hi, > > I have followed this thread with interest since there are many good > suggestions and ideas. As Lukas mentioned it would be good if we could agree > on some action(s) in which the community could contribute. > > First some info about what we (The OTP team at Ericsson and the Industrial > Erlang User Group) plan to do. > > - Nicer , better HTML layout of the docs. The Elixir look layout looks quite > nice and since it is overlapping communities it could be good to have the > same or similar layout. The HTML, CSS, Javascript setup seems quite well > thought. > Take a look at > http://elixir-lang.org/docs/stable/elixir/Kernel.html#full-list. > If you have suggestions regarding the html layout they are welcome. In that > case it would be nice with a small example showing for example the beginning > of the lists module and a few functions. Note this step does not require > changes of the doc source which is XML it is just a matter of tooling. > Translating the current XML to html (when you know what html you want). > > - Making it easier to contribute with documentation improvements. One simple > step can be to add a link to the doc source at github from the generated > html page. Another to write a short guide on how to contribute to the > documentation. > > - Having technical writers going through the documentation in order to > correct language and consistency. This is ongoing. > > - Making the search in documentation on www.erlang.org more visible. You can > search on application, modules, functions. > > - Validate the current doc sources with XMLLINT to assure that we are > following our own DTDs. This is almost done and with this in place it is > easy to translate the doc sources to some other format like a simpler XML > dtd (or XSD), asciidoc or even markdown. Note that there is only one common > source for the documentation and it is in XML with a few exceptions. Each > application has a doc/src directory where its documentation source files > are. There is module references for the modules with public APIs and a User > Guide (mostly). > > From this thread I think the following are the most interesting suggestions: > > Examples in the doc > ------------------------------ > > I agree that we need more examples in the documentation. It would for > example be good to have a short example for > almost every function in a module. > > This can be done in various ways. Either embed the example in the text or > have a separate example file in parallell with the text. In both cases I > would like to have the possibility to automatically check the syntax and > execution of the example during the build documentation build process. If > not checked we will soon have a number of non working examples. > > The presentation view of examples is just a tooling question independent on > the actual source for the examples. The first thing is to create the source > for examples and what format we should use for this (same for all modules of > course). > > Man pages or not? > ------------------------- > > I understand that some of you are using the man pages. But the question is > why are you using them? > Is it because it is easy to type "man lists" or "erl -man lists"? What if > "erl -man lists" pops up in a web-browser window of you choice instead?, > Note that it is exactly the same information shown in the lists.html and in > the man page for lists. > > PDF or not? > ------------------ > > I think it is rather unusual that the PDF pages we generate to day are used > compared to the HTML variant. Correct me if I am wrong. > Perhaps Epub or something else would be more useful. I suppose the html > variant could also support printing and or saving as pdf without to much > effort from our side. > > More User Guide oriented text or cook books. > --------------------------------------------------------------- > > This is very valuable but does not have to be part of the Erlang/OTP > release. Could be hosted on a web-site like Erlang Central (and there is > already material like this there I think). > > I have probably forgotten lots of things that I should have mentioned and > commented , but this is it for now. > > /Kenneth, Erlang/OTP , Ericsson > > _______________________________________________ > 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 lloyd@REDACTED Tue Sep 27 19:12:39 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 27 Sep 2016 13:12:39 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: <1474996359.693425826@apps.rackspace.com> A modest suggestion: Can this info be included in an easy to find box, maybe even repeated, somewhere in the Erlang Reference docs? Best, Lloyd -----Original Message----- From: "Kenneth Lundin" Sent: Tuesday, September 27, 2016 7:49am To: "Luke" Cc: "Lukas Larsson" , "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions On Tue, Sep 27, 2016 at 1:11 PM, Luke wrote: > Joe, check out this startup - https://www.simpla.io/ > > They allow editable web pages, which creates blobs which get saves > directly into a database. No more digging through source files to edit > docs, people (with appropriate permission) can edit the page live. It would > be very straightforward to write a program to dump from the database to > XML/JSON or whatever format you're interested in, making it portable, and > fairly trivial to go the other way. (Full disclosure: It's not my startup > but they're my mates, we went through the same accelerator). > > Is the raw XML documentation available anywhere? > The documentation source is in the otp git repository. Each application has a doc/src directory with Makefile and .xml files. The system documentation is under Root/system/doc There are a few tweaks where the source is not XML but instead a Markdown file. /Kenneth > > Thanks, > Luke > > On Tue, Sep 27, 2016 at 6:03 AM, Joe Armstrong wrote: > >> Regarding the documentation - there is a step0 that needs to be done >> *before* attacking the document improvement problem. >> >> The following things are needed (I my opinion) >> >> 1) The number of DTDs in the documentation should be reduced to ONE >> there are currently 26 these are in >> otp_src_/lib/erl_docgen/priv/dtd >> >> 2) tags that are used infrequently should be removed and the source XML >> corrected. Some tags are virtually *never* used. >> >> 3) All XML files should validate with the new DTD >> >> These steps need quite a lot of work ... >> >> 4) The Erlang parser should be changed to exactly >> reproduce the source. >> Right now the parse tree of correct erlang has all the comments >> and white space removed. I'd suggest attaching the comments to the >> next following token (for example {atom,Line,theAtom} should become >> {atom, Line, theAtom, "the preceding comments and white space"} >> It should be possible to *exactly* reconstruct the input from the parse >> tree. >> >> >> >> >> >> >> >> 5) We should decide how to attach "floating" comments in the source. >> Does a comment *before* a function apply to the next function or not? >> >> 6) We need some "injection" API to inject code, meta-data, examples >> and documentations into a data base. >> >> For example inject:code("foo.erl") should inject a load of key/value >> pairs into a data base, with something like the following keys >> >> {text, Mod,Func,Arity} => the source code text >> {spec, Mod, Func, Arity} => the spec >> {doc, Mod,Func,Arity} => the documentation >> {examples,Mod,Func,Arity} = [Examples] >> >> The entities in the database should be sufficient to reconstruct the >> original text, and perform various analysis of the functions. >> >> I think *most* of the problems involved are due to the difficulty of >> extracting information from the source files and editing this when it is >> wrong. >> >> I'm currently trying to do parts of this. >> >> A "relatively simple" program should be able to (for a given function) >> >> - find the exact source text >> - find all old versions >> - find the specs and types referred to >> - find the documentation >> - find the test cases >> >> Doing so involves analysing the erlang sources the XML sources and the >> test cases, and involves a deal of guess work. >> >> All this must be done on a moving target and should not break the >> existing system. >> >> I suspect that the code to accurately manipulate the code and >> documentation have been has been written several times in different >> projects (for example >> the wrangler, and the Eclipse interface) both need to manipulate the >> source >> in various ways. >> >> >> >> >> On Mon, Sep 26, 2016 at 6:41 PM, wrote: >> > Joe, >> > >> > You've said so well what I've been trying to harp on. >> > >> > My most recent timesink has been trying to understand xmerl >> sufficiently well to pull book data out of several different book APIs. >> Dave Thomas's 2007 tutorial has been a big help, but the black holes in my >> understanding still significantly impede my progress. So far I've spent >> maybe 10 to 15 hours trying to scope it out. I can get much of what I need >> from Amazon's APIs, but I need a redundant source. The Library of Congress >> API completely eludes me; I get a little further with ISBNdb, but still not >> far enough. >> > >> > Given discussion on the documentation thread to date, it seems to me >> that there are four issues at stake: >> > >> > 1) Content deficiencies >> > 2) Formatting issues >> > 3) Lack of consensus of what we, as a community, want >> > 4) How we move forward toward comprehensive improvement of >> documentation. >> > >> > Lukas Larsson's most recent post makes a good point. >> > >> > Bruce Yinhe tells me in a private post that his group is about to hire >> one person on a part-time basis to work on documentation improvements. >> > >> > I've lost it in the thread, but as I recall we had some promising >> interest in documentation improvements from an Erricson employee. >> > >> > It would be great if we could begin to rally around these comments and >> find some kind of convergence toward progress. >> > >> > My take is to break the large task down into small chunks, bring the >> intelligence and resources of the community to bear on one specific issue >> at a time and, and get it done. >> >> I think many (most) of the problems arise because what we are ultimately >> doing is changing the content of a file at some place. >> >> Fixing a typo/bug involves >> >> 1- finding the appropriate file >> 2 - changing the file at the appropriate place >> 3 - updating the file (somehow) >> 4 - generating the downstream documents that depend upon the file >> >> All these steps are difficult >> >> We can imagine a simpler way: >> >> Suppose a file is a sequence of paragraphs. Each paragraph >> has a GUId >> >> In (say) HTML >> >>

>> This is my paragarph ... >>

>> >> If I want to update the paragraphs I just send a message >> >> {update,"b92a2705-3449-4fb9-8f11-fa55f7ead29f" >> "the new content"} >> >> to some server - this should be checked (manually) and then >> if approved used to update everything. >> >> In other threads I have argued that *everything* should be in a global >> database with a huge DHT tracking where things are. >> >> A key to "changing things" is "naming things" and "finding things" >> >> yes another (even simpler) alternative is to have a message >> >> {change,SHA,NewText} >> >> Meaning "change the paragraph with sha1 checksum to " >> >> Implementing this is easy - BUT all paragraphs with the same SHA >> would be changed - which might not be what we want. >> >> I have (incidentally) experimented with this - tagging all paragraphs >> with their SHAs and sticking the results in a database. >> >> >> make a server that accepts messages of the form >> >> {change, , } >> >> The server finds a paragraph with sha1 checksum and changes >> it to - it changes the appropriate file in a GIT archive >> does all the /add/commit/push magic and the job is done. >> >> (I think I'll implement this for fun :-) >> >> >> >> > >> > I don't have the technical chops, but I'll gladly work with you or >> anyone else to address content issues on a module-by-module basis. I can >> ask Micky-the_Dunce questions and, perhaps, help clarify language. It would >> be great if you could help clarify intent and application issues. >> > >> > All the best, >> > >> > Lloyd >> > >> > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: "Joe Armstrong" >> > Sent: Monday, September 26, 2016 6:42am >> > To: "Lukas Larsson" >> > Cc: "Lloyd R. Prentice" , " >> erlang-questions@REDACTED" >> > Subject: Re: [erlang-questions] Erlang documentation -- a modest >> proposal >> > >> > I think what I miss most are *examples* >> > >> > I've just been reading the edoc manual pages for a program >> > called (name changed to avoid embarrassment) >> > >> > The functions are well documented - they types are well documented >> > but I haven't a clue about which ORDER to call the functions >> > >> > Imagine a file system. >> > >> > We *document* the open, read, write, and close functions >> > but we don't say you have to open the file before we read it. >> > We dont say when we're done we have to close the file. >> > >> > We don't say this because it is *obvious* >> > >> > But for the module glonk, which exports, zizzle, taddle, glonk and plonk >> > it is NOT obvious. Yes sure you all know you have to call glonk 3 times >> > before calling plonk - but I don't know. >> > >> > Thats why we need examples. >> > >> > Often I search for a tutorial and find a ten line blog posting that >> > actually shows me how to use a library - this gets me started. >> > >> > very short unit tests - placed inline are *very* useful >> > >> > for example: >> > >> > "321" = lists:reverse("123") >> > >> > The unit test *are* the examples - what we don't have is software that >> > parses the code, parses the documentation, parses the unit test >> > and munges all together into a form that is convenient to read. >> > >> > I'm actually trying to write something like this now - hence my wails >> > of anguish over css. >> > >> > Wish me luck >> > >> > /Joe >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Sep 26, 2016 at 11:58 AM, Lukas Larsson >> wrote: >> >> Hello, >> >> >> >> On Thu, Sep 22, 2016 at 11:56 PM, Lloyd R. Prentice < >> lloyd@REDACTED> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> To date, this thread has generated quite a few worthwhile insights and >> >>> ideas. My fear is that they will be deep-sixed into the archive. On >> the >> >>> other hand, major revision is a daunting task and unlikely to happen. >> >>> >> >>> But maybe we can focus on specific issues and make iterative headway. >> >>> >> >>> Fewer than half of the functions in the lists library, for instance, >> have >> >>> code examples. Suppose over the span of one week we were collectively >> focus >> >>> on generating at least two code examples for each function in one >> library. >> >>> >> >>> At the end of the week we could organize the submissions and vote on >> best >> >>> candidates for inclusion in the docs. That done, we can pick another >> module. >> >>> >> >>> Thus, with not much effort from any one individual, a small posse of >> >>> volunteer Erlang wizards could make short work of deficiencies in the >> docs. >> >>> >> >>> Anyway, it's an idea. >> >>> >> >>> All the best, >> >>> >> >>> LRP >> >>> >> >> >> >> I think that it is great to see everyone talking about wanting to >> improve >> >> the documentation. The contributions to the Erlang/OTP project that I >> value >> >> that most are documentation changes that make the intention clearer, or >> >> explains some corner case somewhere which the docs did not initially >> >> mention. >> >> >> >> Unfortunately, once one has figured out how a function works there >> seems to >> >> be very little incentive to make the docs clearer. I would estimate >> that >> >> about every 20th pull request we get is a documentation fix, and more >> than >> >> half of those are fixes of speling misstakes (which are great!). >> >> >> >> I've just come back from about two weeks of vacation and this >> discussion has >> >> resulted in roughly 0 pull requests for changes in the documentation. >> Would >> >> it be possible to steer this discussion into doing something instead of >> >> talking about doing something? Yes the technology/layout is not >> perfect, but >> >> as Lo?c said, it is the content that matters the most. >> >> >> >> Lukas >> >> // my own oppinions >> >> >> >> _______________________________________________ >> >> 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 fly@REDACTED Tue Sep 27 19:27:45 2016 From: fly@REDACTED (Fred Youhanaie) Date: Tue, 27 Sep 2016 18:27:45 +0100 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <1474995526.635215018@apps.rackspace.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> <1474995526.635215018@apps.rackspace.com> Message-ID: <728ac705-192f-d5b4-1872-87a388b8d031@anydata.co.uk> I use pandoc on regular basis. Mainly to convert saved html files, blogs/articles, to epub, then from epub to mobi (Kindle) via calibre. It uses an intermediate internal format, so one only needs to write input/output converters for each format. Works well, written in Haskell - Erlang's Cousin ;-) Cheers, f. On 27/09/16 17:58, lloyd@REDACTED wrote: > I haven't used it yet, but Pandoc looks promising. > > http://pandoc.org/ > > Best to all, > > LRP > > -----Original Message----- > From: "Kenneth Lundin" > Sent: Tuesday, September 27, 2016 5:08am > To: "Lo?c Hoguin" > Cc: "Lukas Larsson" , "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > On Tue, Sep 27, 2016 at 10:39 AM, Lo?c Hoguin wrote: > >> On 09/27/2016 09:44 AM, Kenneth Lundin wrote: >> >>> Man pages or not? >>> ------------------------- >>> >>> I understand that some of you are using the man pages. But the question >>> is why are you using them? >>> Is it because it is easy to type "man lists" or "erl -man lists"? What >>> if "erl -man lists" pops up in a web-browser window of you choice >>> instead?, Note that it is exactly the same information shown in the >>> lists.html and in the man page for lists. >>> >> >> It would be terrible for many reasons: >> >> * lack of search; command line manual search is very useful (man -k and >> others) >> > I don't think the search has to be worse in the html form, it depends on > how we do it. > > >> * man pages are readable in 80x24 windows; browsers aren't >> > Have you tried lynx? a text based web-browser I think our html pages looks > quite good in that one. > > >> * opening in a separate window is awkward; currently I need to do this to >> have what I need: Menu key (opens a terminal), "man lists"; with what you >> suggest I need at least a couple more steps >> * if i want to have the manual side by side with the code, I need a >> different browser or browser window; I already fight with Dialyzer because >> it runs out of memory on some modules, I don't need the waste browsers add >> on top of that >> >> Also note that in the absence of man pages, I'd look first into 'info' or >> PDF formats before I consider local HTML. HTML is just not practical for >> manuals. >> >> I'm also wondering why the intent to remove man/PDF formats. They're >> already working, it doesn't sound like they would need much maintenance to >> be kept, they have users, so why consider removing them? It doesn't make >> much sense to me. > > > html, pdf and man are 3 different backends for generating documentation of > course it will cost more to maintain and develop 3 backends instead of 1 or > 2. This is especially true if new features are introduced in the document > source format or if we even change the format completely. > > But this is just a possibility (to remove formats that are not so much > used) , no decision is taken. > > Interesting would be to know how many % of the users that actually are > using the man and pdf pages. > > /Kenneth, Erlang/OTP Ericsson > >> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> Author of The Erlanger Playbook, >> A book about software development using Erlang >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From jesper.louis.andersen@REDACTED Tue Sep 27 20:01:04 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 27 Sep 2016 20:01:04 +0200 Subject: [erlang-questions] Running a Unix Subprocess In-Reply-To: References: Message-ID: My advice is to use Serge Aleynikov's "erlexec" for this: https://github.com/saleyn/erlexec It is built for exactly the purpose of handling "bad UNIX processes" in a way which makes them somewhat more in alignment with what Erlang provides. In particular, you can receive monitor-like events if the external process dies. It also handles the close-down of UNIX processes, should the Erlang system die. And so on. In short, it solves a lot of problems you would have to solve yourself otherwise. On Tue, Sep 27, 2016 at 11:19 AM, Zachary Kessin wrote: > Hi all > > I want to run a sub process that will connect via StdIn and StdOut. Is > there an easy way to do this? I had thought to use a port but as the child > process was not written with the assumption that it is running inside a > port i don't want to have to prepend length bytes onto the inputs and > outputs. > > Is there an easy way to do this in erlang? > > -- > Zach Kessin > SquareTarget > Twitter: @zkessin > Skype: zachkessin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yueyoum@REDACTED Tue Sep 27 20:39:41 2016 From: yueyoum@REDACTED (=?UTF-8?B?5pyI5b+n6IyX?=) Date: Wed, 28 Sep 2016 02:39:41 +0800 Subject: [erlang-questions] shell is much slower than escript ? Message-ID: I have s simple code to create and update maps. and using timer:tc to measure the time costed by this operations. file aa.erl -module(aa). -export([create/1, update/1]). -record(person, {id, x, y, angle, speed}). create(Num) -> create(Num, #{}). update(M) -> Size = maps:size(M), Fun = fun(K, V) -> X = Size - K, V#person{x=X,y=X,angle=X,speed=X} end, maps:map(Fun, M). create(0, M) -> M; create(N, M) -> M1 = M#{N => #person{id=N, x=N, y=N, angle=N, speed=N}}, create(N-1, M1). ----------------------------- file aa.escript #!/usr/bin/env escript main(_) -> io:format("Start~n"), {T, M} = timer:tc(aa, create, [10000]), io:format("create cost ms: ~p~n", [T / 1000]), {T1, M1} = timer:tc(aa, update, [M]), io:format("update cost ms: ~p~n", [T1 / 1000]), ok. --------------------------------------- When run with escript, the outputs are: wang[02:31][~/Learn]$ ./aa.escript ./aa.escript:11: Warning: variable 'M1' is unused Start create cost ms: 7.344 update cost ms: 5.903 wang[02:31][~/Learn]$ ./aa.escript ./aa.escript:11: Warning: variable 'M1' is unused Start create cost ms: 7.077 update cost ms: 5.484 wang[02:31][~/Learn]$ ./aa.escript ./aa.escript:11: Warning: variable 'M1' is unused Start create cost ms: 7.006 update cost ms: 5.438 wang[02:31][~/Learn]$ -------------------------------------------- But when I run in erl shell, the outputs are: wang[02:32][~/Learn]$ erl Erlang/OTP 19 [erts-8.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V8.0 (abort with ^G) 1> {T, M} = timer:tc(aa, create, [10000]). {19523, #{462 => {person,462,462,462,462,462}, 704 => {person,704,704,704,704,704}, 7994 => {person,7994,7994,7994,7994,7994}, 6850 => {person,6850,6850,6850,6850,6850}, 6836 => {person,6836,6836,6836,6836,6836}, 9765 => {person,9765,9765,9765,9765,9765}, 6653 => {person,6653,6653,6653,6653,6653}, 5961 => {person,5961,5961,5961,5961,5961}, 1328 => {person,1328,1328,1328,1328,1328}, 4351 => {person,4351,4351,4351,4351,4351}, 8373 => {person,8373,8373,8373,8373,8373}, 6749 => {person,6749,6749,6749,6749,6749}, 9406 => {person,9406,9406,9406,9406,9406}, 8441 => {person,8441,8441,8441,8441,8441}, 6570 => {person,6570,6570,6570,6570,6570}, 6074 => {person,6074,6074,6074,6074,6074}, 3590 => {person,3590,3590,3590,3590,3590}, 7636 => {person,7636,7636,7636,7636,7636}, 5934 => {person,5934,5934,5934,5934,5934}, 4631 => {person,4631,4631,4631,4631,4631}, 1935 => {person,1935,1935,1935,1935,1935}, 8406 => {person,8406,8406,8406,8406,...}, 9860 => {person,9860,9860,9860,...}, 3742 => {person,3742,3742,...}, 9221 => {person,9221,...}, 4969 => {person,...}, 9846 => {...},...}} 2> T / 1000. 19.523 3> 3> {T1, M1} = timer:tc(aa, update, [M]). {16920, #{462 => {person,462,9538,9538,9538,9538}, 704 => {person,704,9296,9296,9296,9296}, 7994 => {person,7994,2006,2006,2006,2006}, 6850 => {person,6850,3150,3150,3150,3150}, 6836 => {person,6836,3164,3164,3164,3164}, 9765 => {person,9765,235,235,235,235}, 6653 => {person,6653,3347,3347,3347,3347}, 5961 => {person,5961,4039,4039,4039,4039}, 1328 => {person,1328,8672,8672,8672,8672}, 4351 => {person,4351,5649,5649,5649,5649}, 8373 => {person,8373,1627,1627,1627,1627}, 6749 => {person,6749,3251,3251,3251,3251}, 9406 => {person,9406,594,594,594,594}, 8441 => {person,8441,1559,1559,1559,1559}, 6570 => {person,6570,3430,3430,3430,3430}, 6074 => {person,6074,3926,3926,3926,3926}, 3590 => {person,3590,6410,6410,6410,6410}, 7636 => {person,7636,2364,2364,2364,2364}, 5934 => {person,5934,4066,4066,4066,4066}, 4631 => {person,4631,5369,5369,5369,5369}, 1935 => {person,1935,8065,8065,8065,8065}, 8406 => {person,8406,1594,1594,1594,...}, 9860 => {person,9860,140,140,...}, 3742 => {person,3742,6258,...}, 9221 => {person,9221,...}, 4969 => {person,...}, 9846 => {...},...}} 4> 4> T1 / 1000. 16.92 5> the create time is 19ms, and update time is 17ms the escript running time is 7ms and 5 ms. Why in the erl shell, there is slower than escript? So, when I run my erlang application via: erl -pa xxx -s myapp start -detached . Is it as slow as running with erl shell ? -- My GitHub https://github.com/yueyoum -------------- next part -------------- An HTML attachment was scrubbed... URL: From Catenacci@REDACTED Tue Sep 27 20:53:49 2016 From: Catenacci@REDACTED (Onorio Catenacci) Date: Tue, 27 Sep 2016 14:53:49 -0400 Subject: [erlang-questions] Rough Time Message-ID: Hi all, I thought this might present some interest to some of the folks on this mailing list. https://roughtime.googlesource.com/roughtime -- Onorio Catenacci http://onor.io http://www.google.com/+OnorioCatenacci -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Sep 28 01:05:59 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 28 Sep 2016 12:05:59 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <130e0664-8695-ba8d-db6e-418f106d40f0@gmail.com> <0169ee54-6545-095a-b748-83fb6d7887be@cs.otago.ac.nz> <0342901b-2640-a135-6031-5151abb0e83e@ninenines.eu> <98209ec5-295d-6e34-4425-4c49504a17d2@ninenines.eu> <732a5f7f-0261-14e2-9479-6fb4b59feadc@cs.otago.ac.nz> Message-ID: The version of Lout I have is 3.40 (June 2013). The mailing list (http://lists.nongnu.org/archive/html/lout-users/) is still active, although traffic is low. Jeff Kingston is still around but seems to be focussing on timetabling problems these days. I have yet to meet a C program that clang does not complain about (until I've bashed on it until clang shuts up, but then the next release of clang complains about something else). Considering that when Lout was first released, lint spewed thousands of warnings (leading me to find some actual and potentially serious bugs), it is surprising how little kvetching clang does. (Most of it about signed shifts, which I've been using in C since 1979 and can't really manage without.) Lout was originally written to generate PostScript. It now has a PDF back-end as well. Some things aren't yet supported, but there's always ps2pdf. Apple's Preview sometimes has a hissy fit over Lout's PostScript -- without actually saying why -- but Ghostscript is perfectly happy with it, so I'm not sure which program needs fixing. (Given the problems I've had with Apple's Mail I'd guess it's Preview.) Just to make sure it still works I reinstalled it, and I must say that building Lout, installing it, and regenerating the documentation went very smoothly, in *marked* contrast to Asciidoc or any version of Markdown I've ever tried. From ok@REDACTED Wed Sep 28 01:14:37 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 28 Sep 2016 12:14:37 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> Message-ID: <8caacbb6-163a-5c73-5422-625008841838@cs.otago.ac.nz> Concerning the abstract syntax tree and recording absolutely everything about the source code in it; is this really necessary? What SWI Prolog does to support its debugger is - retain the source text in a file - in the AST, record the beginning and length of each term. For Erlang, 16#fc would be tokenised as {integer,{location,Line,Col,Start,Length},252} For a Prolog dialect converter I wrote, I adopted the rule that % comments with a preceding token on the same line were attached to the *preceding* term while % comments without such a token were attached to the *following* term, with %comments preceding a predicate attached to the following predicate as a whole. Thus % following predicate foo(...) :- % foo(...) % bar(...) bar(...), % also bar(...). ugh(...). % ugh(...) This seemed to fit user expectations pretty well. From ok@REDACTED Wed Sep 28 02:01:36 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 28 Sep 2016 13:01:36 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: On 27/09/16 9:39 PM, Lo?c Hoguin wrote: > On 09/27/2016 09:44 AM, Kenneth Lundin wrote: >> Man pages or not? >> ------------------------- >> >> I understand that some of you are using the man pages. But the question >> is why are you using them? >> Is it because it is easy to type "man lists" or "erl -man lists"? What >> if "erl -man lists" pops up in a web-browser window of you choice >> instead?, I want to agree with everything Lo?c Hoguin wrote in response. I've been through this. I have R installed on a desktop Mac and a laptop Mac. On both of them, you can do either % R to run R in an existing terminal window, or % open -a R to open a native GUI. If you type > ?pmax then the terminal version lets you page through plain text, very like man(1), but the GUI version pops up a window which I presume to be run by WebKit inside the GUI, links work &c. Add to this the fact that the GUI version opens native graphics windows while the terminal version has to fire up X11 (not normally running) in order to give you an X11 window for graphics. So it's a clear win for the GUI app, right? Well, no. For example, it quite often happens that I ssh from the laptop (which might be at home) to the desktop in order to try something out on data held on the desktop. If the terminal version popped up a window to display help, it would pop up on the desktop screen, which I would be too many kilometres away from to see. Did I mention that the R gui pays no attention to the font size I have selected for my interaction window, and always pops up its help window in the same markedly smaller font? Seriously proctalgic. So when seated at my desktop machine, I quite often run the command-line version of R in order to *AVOID* the browser-style help. Now there are times when I *want* to go a-wandering, hey clickety clickety nonny no, and then % open `htman foobar` is fine. It's nice to have AS WELL. It is nearly unforgivable to have INSTEAD. A really nice thing about having the Erlang manual pages is that I can read them without having to involve Erlang or a web browser at all. The R documentation is superb, but I really hate the fact that there's no documented way to get to it except through R. The only thing better than being able to do % man lists would be being able to do % man lists:sort From ok@REDACTED Wed Sep 28 03:19:59 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 28 Sep 2016 14:19:59 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <90911491-9f74-78db-53b8-47beaae069a0@ninenines.eu> Message-ID: <975b8e89-c3e2-c07e-e77c-43f620465697@cs.otago.ac.nz> On 27/09/16 10:08 PM, Kenneth Lundin wrote: > * lack of search; command line manual search is very useful (man -k > and others) > > I don't think the search has to be worse in the html form, it depends on > how we do it. I don't want to have to depend on how *you* do it. It *will* be worse *until* you do something about it, and you already have copious demands on your time. > > * man pages are readable in 80x24 windows; browsers aren't > > Have you tried lynx? a text based web-browser I think our html pages > looks quite good in that one. Guess what? lynx doesn't come standard with OSX. Oh GOODY! Just what I needed! In order to read documentation, I have to install a NEW tool different from everything else I use to read documentation! WOW! Fantastic! /sarc Seriously, I mean *really* seriously, every system I use (Solaris, Linux, OSX, Cygwin) comes with man. I'm using it all the time. If I want a hypertexty thing that works in a terminal window or in a certain powerful text editor, there's info. I don't use that _all_ the time, but I use it a _lot_ more than Lynx. Info actually came on all the systems I use, possibly as part of something else, but I didn't have to go and get it. > I'm also wondering why the intent to remove man/PDF formats. They're > already working, it doesn't sound like they would need much > maintenance to be kept, they have users, so why consider removing > them? It doesn't make much sense to me. > > > html, pdf and man are 3 different backends for generating documentation > of course it will cost more to maintain and develop 3 backends instead > of 1 or 2. This is especially true if new features are introduced in the > document source format or if we even change the format completely. This is a very strong argument in favour of keeping the document source format simple and not getting too fancy with the output. Of course, the claim that the current HTML pages look good in Lynx ceases to be relevant if the generated HTML is changed much. I pointed out to my concurrent programming students yesterday the need for protocols to be versioned, and specifically pointed to HTML as something that used to get this right (the doctype line said which version of HTML a document was intended to be in) where that has been lost for entirely bogus reasons. HTML5 doesn't have a DTD, so the doctype line no longer has *any* form of version information in it, which would be fine if HTML was now frozen for all time, but it isn't. It is still advisable not to get too fancy with the HTML you generate. (Does Lynx support all of HTML5? Thought not.) The argument for markdown or asciidoc is that they have lots of back ends that other people are maintaining. ronn(1) https://rtomayko.github.io/ronn/ronn.1.html for example converts a dialect of Markdown to man pages or HTML. https://github.com/rtomayko/ronn#readme offers an argument for retaining man pages. pandoc can also generate man pages, HTML, or PDF from Markdown. > > But this is just a possibility (to remove formats that are not so much > used) , no decision is taken. Take the existence of man pages as an incentive to focus on content rather than flashy images. Form liberates! I have noticed a common tendency for people to abuse the principle of mediocrity: [Someone tasked with cooking a meal] I am not hungry, so nobody is hungry. [Someone tasked with supporting Haskell] I do not use Windows, so it is not important to support Haskell on Windows. [Someone tasked with documentation] I do not use man any more so nobody needs man any more. From ok@REDACTED Wed Sep 28 03:58:49 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 28 Sep 2016 14:58:49 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: > > Have you looked at the Elixir doc for > example http://elixir-lang.org/docs/stable/elixir/Kernel.html? I have. I see EXTREMELY wide margins in the main panel. This is a waste of my screen real estate and gives me a bad feeling straight away. I see SMALL characters in the main panel. I've actually told my browser never to show characters as smaller than 14pt, but somehow the Elixir page is overriding that. By the way, this already raises a MAJOR accessibility issue. Tim Berners-Lee always wanted HTML to be usable by people who had poor vision or none. One of the points of using Cascading Style Sheets is that the user is supposed to be able to set defaults (like no small text) that the web page cannot (or at least should not) override. That means that setting font sizes is a VERY user-hostile thing for a web designer to do, and means that you have (or at least should exert) much less control over layout than you think. There is something worse. The code examples on the page are in an even SMALLER font than the text, and they are in pale colours (pale orange, pale purple) against a white background, making them even HARDER to see. In the summary, the text is in italics for no apparent reason. On the evidence so far, I can only assume that the reason is to make it harder to read. So just at first glance I can tell that the author hates me. And this you think is "quite good"? I see a dark blue? grey? purple navbar. The text is even SMALLER than the code text in the main panel, and appears to be pale blue against dark blue. It's a strain to read. It's a list of modules. The fact that it is possible to get a list of functions is far from obvious. (I expected it to be a link.) It doesn't help that I find dark colours depressing and my eyes automatically turn away from big dark blobs, so it takes conscious effort to attend to the navbar. It's just so dark and ugly. Not content with wasting about half of the horizontal extent of the main panel, when I go to the "Functions" part of the page, it wastes about half of the vertical extent of the main panel with unnecessary white space. It wastes much of the rest with trivial examples. I love examples, but I do not want to see them ALL the time. And this you think is "quite good"? While I'm no spring moa, I have new glasses and am accepted as fine for driving, and am comfortable reading printed 10-point type. (Why then do I set 14pt minimum in the browser? High resolution screen, and designers who count pixels instead of points. Web designers tend to assume that their resolution is everyone's resolution. I remember being slammed as a moron by one web designer for not knowing that screen resolutions higher than 72 dots per inch didn't exist, at a time when I was using a Mac with 90 dots per inch.) I am prepared to swear in court that man pages are much easier for me to read than this web page. It is clear that a huge amount of work has gone into the Elixir web pages, trying to make them visually attractive. (Abuse of the principle of mediocrity: If I like it, everyone likes it.) And it's also clear that a lot of effort has gone into providing examples. It's just that for me the Elixir pages are unpleasant *because* of the work that has gone into them. It seems pretty obvious that HTML pages that *I* think are beautiful will look horrible to someone else. > I think the layout and function is quite good and the handling of css > and javascript is from what I can understand > handled nicely. I can't think of any good reason for Erlang documentation pages to contain any JavaScript whatsoever. Lynx doesn't include a JavaScript interpreter, and Emacs-W3 doesn't include a JavaScript interpreter, and for that matter, one of the web browsers I use from time to time doesn't include a JavaScript interpreter. (No, navbars *don't* need JavaScript.) For search, I'd like to use a proper IR engine. You *really* don't want to load an IR index into every page. From eric.pailleau@REDACTED Wed Sep 28 07:22:19 2016 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Wed, 28 Sep 2016 07:22:19 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <8caacbb6-163a-5c73-5422-625008841838@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> <8caacbb6-163a-5c73-5422-625008841838@cs.otago.ac.nz> Message-ID: Hi, I see an interest in keeping all source code in abstract code at least as a compilation option. This could allow to beautify code automatically with the rules of owner by rewriting back to disk the source code. Numbers of blanks per tabulation, max width of code, some want 80 colons, some other 100 for example. This could help to create a tool to let respect the coding standard of owner project. Regards "Envoy? depuis mon mobile " Eric ---- Richard A. O'Keefe a ?crit ---- >Concerning the abstract syntax tree and recording absolutely >everything about the source code in it; is this really >necessary? > >What SWI Prolog does to support its debugger is >- retain the source text in a file >- in the AST, record the beginning and length of each term. >For Erlang, 16#fc would be tokenised as > {integer,{location,Line,Col,Start,Length},252} > >For a Prolog dialect converter I wrote, I adopted the rule >that % comments with a preceding token on the same line were >attached to the *preceding* term while % comments without >such a token were attached to the *following* term, with >%comments preceding a predicate attached to the following >predicate as a whole. Thus > > % following predicate > foo(...) :- % foo(...) > % bar(...) > bar(...), % also bar(...). > ugh(...). % ugh(...) > >This seemed to fit user expectations pretty well. >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Sep 28 07:52:48 2016 From: ok@REDACTED (ok@REDACTED) Date: Wed, 28 Sep 2016 18:52:48 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> <8caacbb6-163a-5c73-5422-625008841838@cs.otago.ac.nz> Message-ID: > Hi, > I see an interest in keeping all source code in abstract code at least as > a compilation option. By the time you have included the original spelling of every token, all white space, and every comment in your AST (which is what Joe was talking about), you have replicated the *concrete* form of the source code, just broken up into little bits. If you record the source code (in some compressed form), and you record the start and length of every term, you can extract the source code for any term effortlessly, no concatenation required. We already have the option to store an AST in a BEAM file, I believe. By the way, Joe, do remember my proposal years ago to hold Erlang source code in SGML? I don't remember if I mentioned back then that you can compile straight out of the SGML. The VisualWorks Smalltalk system holds source code in XML and loads "parcels" directly from the XML form. (Once it gets down to the equivalent of a single function clause it stops and switches to plain text, but there's no need for it to do so.) From eric.pailleau@REDACTED Wed Sep 28 07:53:17 2016 From: eric.pailleau@REDACTED (=?ISO-8859-1?Q?=C9ric_Pailleau?=) Date: Wed, 28 Sep 2016 07:53:17 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> <8caacbb6-163a-5c73-5422-625008841838@cs.otago.ac.nz> Message-ID: Forgot to say that sometimes I use the below example from beam_lib documentation to beautify the code, and add comments after. {ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]). io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]). "Envoy? depuis mon mobile " Eric ---- ?ric Pailleau a ?crit ---- >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Sep 28 09:06:09 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 28 Sep 2016 09:06:09 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <1474908100.763928884@apps.rackspace.com> <8caacbb6-163a-5c73-5422-625008841838@cs.otago.ac.nz> Message-ID: On Wed, Sep 28, 2016 at 7:52 AM, wrote: > > Hi, > > I see an interest in keeping all source code in abstract code at least as > > a compilation option. > > By the time you have included the original spelling of every token, > all white space, and every comment in your AST (which is what Joe > was talking about), you have replicated the *concrete* form of the > source code, just broken up into little bits. Yes, and sometimes this is just what one needs. Any tool that processes/transforms source code needs an AST for the source _before preprocessing_, so that it can know about macros and ifdefs. Then cross-referencing will include all types of tokens and all instances of those, not just those that survived the preprocessor. This is useful for example when renaming a function or macro. Even pretty-printing can use this (for example to gray out the parts of the source that are currently removed by the preprocessor). Newer code is much nicer to parse, as heavy usage of macros and ifdefs is avoided, but there is always old code that nobody really wants to touch, but has to be considered. Also we need to consider the proposed OTP version macros (EEP 44 https://github.com/erlang/eep/blob/master/eeps/eep-0044.md) that would make it possible to provide multiple versions of a function in the same file, each possibly with their own edoc documentation blob (even if it is arguably better to keep the docs separate, a lot of projects today use inline docs with edoc). > If you record the > source code (in some compressed form), and you record the start and > length of every term, you can extract the source code for any term > effortlessly, no concatenation required. > > We already have the option to store an AST in a BEAM file, > I believe. > Yes, the key word being _an_ - some use cases need another AST. Processing source code for compiling has different requirements than for searching/transforming it. best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hoch@REDACTED Wed Sep 28 10:34:42 2016 From: csaba.hoch@REDACTED (Csaba Hoch) Date: Wed, 28 Sep 2016 10:34:42 +0200 Subject: [erlang-questions] Running a Unix Subprocess In-Reply-To: <20160927130426.11a0aed1@gmail.com> References: <20160927130426.11a0aed1@gmail.com> Message-ID: Here is a short example of starting a process and reading its stdout with open_port (you need to modify it to pass your own stdin, but it might be a useful example nevertheless): http://erlang.org/pipermail/erlang-questions/2007-February/025210.html Csaba On Tue, Sep 27, 2016 at 11:34 AM, Ameretat Reith wrote: > On Tue, 27 Sep 2016 12:19:53 +0300 > Zachary Kessin wrote: > >> Hi all >> >> I want to run a sub process that will connect via StdIn and StdOut. Is >> there an easy way to do this? I had thought to use a port but as the >> child process was not written with the assumption that it is running >> inside a port i don't want to have to prepend length bytes onto the >> inputs and outputs. >> >> Is there an easy way to do this in erlang? >> > > User erlang:open_port [1]. Example: > > erlang:open_port({spawn_executable, "/bin/cat"}, [eof, exit_status]). > > This will open a port and execute "/bin/cat" in it, wait until standard > input is closed (eof), reply exit status after cat termination > (exit_status). If you want process get standard input and output of > caller, pass use_stdio option. > > > 1: http://erlang.org/doc/man/erlang.html#open_port-2 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Wed Sep 28 10:55:29 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 28 Sep 2016 10:55:29 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: On Wed, Sep 28, 2016 at 3:58 AM, Richard A. O'Keefe wrote: > > >> Have you looked at the Elixir doc for >> example http://elixir-lang.org/docs/stable/elixir/Kernel.html? >> > > I have. > I see EXTREMELY wide margins in the main panel. > This is a waste of my screen real estate and gives me > a bad feeling straight away. I see SMALL characters in the main panel. > I don't know what Kenneth wanted to highlight with the Elixir docs, but I don't think that he meant the exact presentation. What I looked at is the different structure and what things are emphasized. The details are easy to fix (font sizes, colors, placement, etc) if the underlying HTML is friendly to it (i.e. not everything is a

, but there are selectors for "summary", "examples", "specs", etc). I can only see one major difference: the function list for a module is inline (elixir) instead of in the sidebar (erlang). Which one is best? I've heard people arguing for both. IMHO, presenting reference documentation so that everybody is pleased is extremely difficult, because people use the docs in many different ways. Different layout and information detail are most useful for beginners (that browse to see what's available and might learn something unrelated in the process) than for people that mostly know what they look for (that need fast access to some detail, often from the shell). It's also difficult to create a presentation that works for a full-blown browser as well as for lynx. I'm not referring to the visuals, but the module and function index, which is huge and needs to be folded. I can't come up with a way to do that without javascript. BTW, it's trivial (see comment above regarding html friendliness, though) to make the erlang docs look more like elixir's while keeping the good parts. See picture :-) https://www.dropbox.com/s/jqpqpcimv3qxdce/e0.png?dl=0 regards, Vlad > I've actually told my browser never to show characters > as smaller than 14pt, but somehow the Elixir page is > overriding that. > > By the way, this already raises a MAJOR accessibility > issue. Tim Berners-Lee always wanted HTML to be usable > by people who had poor vision or none. One of the points > of using Cascading Style Sheets is that the user is > supposed to be able to set defaults (like no small text) > that the web page cannot (or at least should not) override. > That means that setting font sizes is a VERY user-hostile > thing for a web designer to do, and means that you have > (or at least should exert) much less control over layout > than you think. > > There is something worse. The code examples on the page > are in an even SMALLER font than the text, and they are > in pale colours (pale orange, pale purple) against a white > background, making them even HARDER to see. > > In the summary, the text is in italics for no apparent > reason. On the evidence so far, I can only assume that the > reason is to make it harder to read. > > So just at first glance I can tell that the author hates me. > > And this you think is "quite good"? > > I see a dark blue? grey? purple navbar. The text is even > SMALLER than the code text in the main panel, and appears to > be pale blue against dark blue. It's a strain to read. > It's a list of modules. The fact that it is possible to > get a list of functions is far from obvious. (I expected > it to be a link.) > > It doesn't help that I find dark colours depressing and my > eyes automatically turn away from big dark blobs, so it > takes conscious effort to attend to the navbar. It's just > so dark and ugly. > > Not content with wasting about half of the horizontal extent > of the main panel, when I go to the "Functions" part of the > page, it wastes about half of the vertical extent of the > main panel with unnecessary white space. It wastes much of > the rest with trivial examples. I love examples, but I do > not want to see them ALL the time. > > And this you think is "quite good"? > > While I'm no spring moa, I have new glasses and am accepted > as fine for driving, and am comfortable reading printed > 10-point type. (Why then do I set 14pt minimum in the browser? > High resolution screen, and designers who count pixels instead > of points. Web designers tend to assume that their resolution > is everyone's resolution. I remember being slammed as a moron > by one web designer for not knowing that screen resolutions > higher than 72 dots per inch didn't exist, at a time when I was > using a Mac with 90 dots per inch.) > > I am prepared to swear in court that man pages are much > easier for me to read than this web page. > > It is clear that a huge amount of work has gone into the > Elixir web pages, trying to make them visually attractive. > (Abuse of the principle of mediocrity: If I like it, > everyone likes it.) And it's also clear that a lot of > effort has gone into providing examples. > > It's just that for me the Elixir pages are unpleasant > *because* of the work that has gone into them. > > It seems pretty obvious that HTML pages that *I* think > are beautiful will look horrible to someone else. > > I think the layout and function is quite good and the handling of css >> and javascript is from what I can understand >> handled nicely. >> > > I can't think of any good reason for Erlang documentation pages > to contain any JavaScript whatsoever. Lynx doesn't include a > JavaScript interpreter, and Emacs-W3 doesn't include a JavaScript > interpreter, and for that matter, one of the web browsers I use > from time to time doesn't include a JavaScript interpreter. > (No, navbars *don't* need JavaScript.) > > For search, I'd like to use a proper IR engine. You *really* > don't want to load an IR index into every page. > > _______________________________________________ > 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 Wed Sep 28 11:19:09 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 28 Sep 2016 11:19:09 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: > I can only see one major difference: the function list for a module is inline (elixir) instead of in the sidebar (erlang). Which one is best? I've heard people arguing for both. You can actually see the functions list in the sidebar too. However it is not obvious you can click on "Functions" on the sidebar to get to the full list of functions. I have already reported a bug so we fix this in the next release! As you said, some people prefer the inline listing, opposite to the sidebar, because the inline includes a one-line summary about the function. It works great when you are accessing a module for the first time and you want to have an overall idea about what each function does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Wed Sep 28 11:21:20 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 28 Sep 2016 11:21:20 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: > I've actually told my browser never to show characters as smaller than 14pt, but somehow the Elixir page is overriding that. I could not reproduce this on Safari, Chrome and Firefox. I would appreciate if you could send me your browser and respective version, possibly in private to not derail the discussion, so I can file a proper bug report. We have actually put a good amount of effort to ensure the page scales up and down accordingly when using the browser zoom features, including mobile and other devices. > In the summary, the text is in italics for no apparent reason. On the evidence so far, I can only assume that the reason is to make it harder to read. Good point. I will also open up an issue to discuss the use of italics. > The fact that it is possible to get a list of functions is far from obvious. (I expected it to be a link.) Yup, as mentioned in previous replies, this is already on the bug reports list. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Wed, Sep 28, 2016 at 3:58 AM, Richard A. O'Keefe wrote: > > > >> Have you looked at the Elixir doc for >> example http://elixir-lang.org/docs/stable/elixir/Kernel.html? >> > > I have. > I see EXTREMELY wide margins in the main panel. > This is a waste of my screen real estate and gives me > a bad feeling straight away. > I see SMALL characters in the main panel. > I've actually told my browser never to show characters > as smaller than 14pt, but somehow the Elixir page is > overriding that. > > By the way, this already raises a MAJOR accessibility > issue. Tim Berners-Lee always wanted HTML to be usable > by people who had poor vision or none. One of the points > of using Cascading Style Sheets is that the user is > supposed to be able to set defaults (like no small text) > that the web page cannot (or at least should not) override. > That means that setting font sizes is a VERY user-hostile > thing for a web designer to do, and means that you have > (or at least should exert) much less control over layout > than you think. > > There is something worse. The code examples on the page > are in an even SMALLER font than the text, and they are > in pale colours (pale orange, pale purple) against a white > background, making them even HARDER to see. > > In the summary, the text is in italics for no apparent > reason. On the evidence so far, I can only assume that the > reason is to make it harder to read. > > So just at first glance I can tell that the author hates me. > > And this you think is "quite good"? > > I see a dark blue? grey? purple navbar. The text is even > SMALLER than the code text in the main panel, and appears to > be pale blue against dark blue. It's a strain to read. > It's a list of modules. The fact that it is possible to > get a list of functions is far from obvious. (I expected > it to be a link.) > > It doesn't help that I find dark colours depressing and my > eyes automatically turn away from big dark blobs, so it > takes conscious effort to attend to the navbar. It's just > so dark and ugly. > > Not content with wasting about half of the horizontal extent > of the main panel, when I go to the "Functions" part of the > page, it wastes about half of the vertical extent of the > main panel with unnecessary white space. It wastes much of > the rest with trivial examples. I love examples, but I do > not want to see them ALL the time. > > And this you think is "quite good"? > > While I'm no spring moa, I have new glasses and am accepted > as fine for driving, and am comfortable reading printed > 10-point type. (Why then do I set 14pt minimum in the browser? > High resolution screen, and designers who count pixels instead > of points. Web designers tend to assume that their resolution > is everyone's resolution. I remember being slammed as a moron > by one web designer for not knowing that screen resolutions > higher than 72 dots per inch didn't exist, at a time when I was > using a Mac with 90 dots per inch.) > > I am prepared to swear in court that man pages are much > easier for me to read than this web page. > > It is clear that a huge amount of work has gone into the > Elixir web pages, trying to make them visually attractive. > (Abuse of the principle of mediocrity: If I like it, > everyone likes it.) And it's also clear that a lot of > effort has gone into providing examples. > > It's just that for me the Elixir pages are unpleasant > *because* of the work that has gone into them. > > It seems pretty obvious that HTML pages that *I* think > are beautiful will look horrible to someone else. > > I think the layout and function is quite good and the handling of css >> and javascript is from what I can understand >> handled nicely. >> > > I can't think of any good reason for Erlang documentation pages > to contain any JavaScript whatsoever. Lynx doesn't include a > JavaScript interpreter, and Emacs-W3 doesn't include a JavaScript > interpreter, and for that matter, one of the web browsers I use > from time to time doesn't include a JavaScript interpreter. > (No, navbars *don't* need JavaScript.) > > For search, I'd like to use a proper IR engine. You *really* > don't want to load an IR index into every page. > > _______________________________________________ > 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 Sep 28 11:22:52 2016 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 28 Sep 2016 11:22:52 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <38AD0A90-B53E-4F52-AD73-7E15F9C27375@gmail.com> Replied inline. > Le 28 sept. 2016 ? 03:58, Richard A. O'Keefe a ?crit : > > > >> >> Have you looked at the Elixir doc for >> example http://elixir-lang.org/docs/stable/elixir/Kernel.html? > > I have. > I see EXTREMELY wide margins in the main panel. > This is a waste of my screen real estate and gives me > a bad feeling straight away. > I see SMALL characters in the main panel. > I've actually told my browser never to show characters > as smaller than 14pt, but somehow the Elixir page is > overriding that. So why do you hardwrap all your emails by hand to 50 columns? You are wasting my real screen estate. Do you hate me? :( How can a website not waste horizontal real estate in huge windows without ending up unreadable because of very long lines of text? This is what your email looks to me btw: https://goo.gl/HLSJ5G > By the way, this already raises a MAJOR accessibility > issue. Tim Berners-Lee always wanted HTML to be usable > by people who had poor vision or none. One of the points > of using Cascading Style Sheets is that the user is > supposed to be able to set defaults (like no small text) > that the web page cannot (or at least should not) override. > That means that setting font sizes is a VERY user-hostile > thing for a web designer to do, and means that you have > (or at least should exert) much less control over layout > than you think. > > There is something worse. The code examples on the page > are in an even SMALLER font than the text, and they are > in pale colours (pale orange, pale purple) against a white > background, making them even HARDER to see. At least you can read the text and see the colours. The Erlang documentation uses iframes and doesn't have navigation links, making it quite useless to screen readers. The colour issues are easily fixable and I think Jos? is happy to get feedback about them. The Erlang documentation accessibility issues are far worse. > In the summary, the text is in italics for no apparent > reason. On the evidence so far, I can only assume that the > reason is to make it harder to read. > > So just at first glance I can tell that the author hates me. > > And this you think is "quite good"? > > I see a dark blue? grey? purple navbar. The text is even > SMALLER than the code text in the main panel, and appears to > be pale blue against dark blue. It's a strain to read. > It's a list of modules. The fact that it is possible to > get a list of functions is far from obvious. (I expected > it to be a link.) > > It doesn't help that I find dark colours depressing and my > eyes automatically turn away from big dark blobs, so it > takes conscious effort to attend to the navbar. It's just > so dark and ugly. > > Not content with wasting about half of the horizontal extent > of the main panel, when I go to the "Functions" part of the > page, it wastes about half of the vertical extent of the > main panel with unnecessary white space. It wastes much of > the rest with trivial examples. I love examples, but I do > not want to see them ALL the time. > > And this you think is "quite good"? Would you prefer 200 characters lines? Because that's not readable by any standard. > While I'm no spring moa, I have new glasses and am accepted > as fine for driving, and am comfortable reading printed > 10-point type. (Why then do I set 14pt minimum in the browser? > High resolution screen, and designers who count pixels instead > of points. Web designers tend to assume that their resolution > is everyone's resolution. I remember being slammed as a moron > by one web designer for not knowing that screen resolutions > higher than 72 dots per inch didn't exist, at a time when I was > using a Mac with 90 dots per inch.) It has been years since CSS pixels' stopped corresponding to device pixels though. > I am prepared to swear in court that man pages are much > easier for me to read than this web page. Most of the text on that webpage is 12pt. Is the size a problem for you, or just the constract issues you mentioned earlier? > It is clear that a huge amount of work has gone into the > Elixir web pages, trying to make them visually attractive. > (Abuse of the principle of mediocrity: If I like it, > everyone likes it.) And it's also clear that a lot of > effort has gone into providing examples. > > It's just that for me the Elixir pages are unpleasant > *because* of the work that has gone into them. > > It seems pretty obvious that HTML pages that *I* think > are beautiful will look horrible to someone else. Would tailoring to your specific needs be abuse of mediocrity? >> I think the layout and function is quite good and the handling of css >> and javascript is from what I can understand >> handled nicely. > > I can't think of any good reason for Erlang documentation pages > to contain any JavaScript whatsoever. Lynx doesn't include a > JavaScript interpreter, and Emacs-W3 doesn't include a JavaScript > interpreter, and for that matter, one of the web browsers I use > from time to time doesn't include a JavaScript interpreter. > (No, navbars *don't* need JavaScript.) Syntax colouring of examples usually need JS because otherwise the HTML markup to be downloaded becomes really heavy. > For search, I'd like to use a proper IR engine. You *really* > don't want to load an IR index into every page. Why not? Indices can be long-time-cached JS assets and then searches are very quick and convenient. Cf. searches on https://doc.rust-lang.org/std/vec/struct.Vec.html for example. Regards. From michal@REDACTED Wed Sep 28 11:33:37 2016 From: michal@REDACTED (=?utf-8?Q?Micha=C5=82_Muska=C5=82a?=) Date: Wed, 28 Sep 2016 11:33:37 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <51FB7FE6-8D28-41A2-9B53-7033DB3BEE1E@muskala.eu> While talking about Elixir documentation everybody seems to focus exclusively on the HTML docs. Surprisingly that's not the primary way of how I (and most of the people I know) interact with the documentation that Elixir provides - the primary way is the direct access to documentation from IEx. I guess that's in many ways similar to the access through man pages, but instead of using an external tool, it comes built-in right into the language itself. In the shell you can use the h/1 helper macro to access documentation on modules (h Kernel), all functions with a particular name (h Enum.reduce) or for a specific function with a particular arity (h Enum.reduce/3). Similarly there are helpers for accessing documentation on behaviours (b/1) and types (t/1). It works both for the standard library and the external packages. For those complaining about use of external tools - here you don't need any of them, only erlang/elixir - no lynx, no man, no browser. This has also a huge advantage of perfectly working offline - again for both the built-in modules as well as all the external dependencies in the exact same way. I cannot stress enough how valuable it is I can access documentation for all the modules I'm using in the same way. Here are some examples: https://www.dropbox.com/s/0eleru83ya6oscg/Screenshot%202016-09-28%2011.29.10.png?dl=0 https://www.dropbox.com/s/x8hg3qyfje0jpmc/Screenshot%202016-09-28%2011.29.53.png?dl=0 https://www.dropbox.com/s/8c15as0cvu46gy0/Screenshot%202016-09-28%2011.31.27.png?dl=0 https://www.dropbox.com/s/0xrqtuhjblixnjb/Screenshot%202016-09-28%2011.32.33.png?dl=0 Related to that is the ability to easily get the documentation programatically from the loaded code with the Code.get_docs/2 function. This allows various tools to access the documentation and present it directly in the code editor or whatever you can imagine. Micha?. From jose.valim@REDACTED Wed Sep 28 11:42:04 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 28 Sep 2016 11:42:04 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <51FB7FE6-8D28-41A2-9B53-7033DB3BEE1E@muskala.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <51FB7FE6-8D28-41A2-9B53-7033DB3BEE1E@muskala.eu> Message-ID: > > Here are some examples: > https://www.dropbox.com/s/0eleru83ya6oscg/Screenshot% > 202016-09-28%2011.29.10.png?dl=0 > https://www.dropbox.com/s/x8hg3qyfje0jpmc/Screenshot% > 202016-09-28%2011.29.53.png?dl=0 > https://www.dropbox.com/s/8c15as0cvu46gy0/Screenshot% > 202016-09-28%2011.31.27.png?dl=0 > https://www.dropbox.com/s/0xrqtuhjblixnjb/Screenshot% > 202016-09-28%2011.32.33.png?dl=0 > Also worth pointing out that the colors and style used by the inline documentation can be customized by creating a file named ~/.iex.exs. You don't need to stick with the colors and formats in the screenshots above. This is documented in the IEx module itself. Since colors have been a concern throughout this discussion, I thought I would mention it upfront. Another advantage of the approach above is that you get the shell autocomplete when looking for help. For example, you can type "h String.", hit tab, and it will list all String functions so you find the proper one you want help on. One big disadvantage of the shell one is that we don't have the page scrolling commands you get with man pages. However, this is a solvable problem, and could be solved by adding document reading features to Erlang's shell. I did a prototype at some point but never made it into a pull request. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Sep 28 11:58:31 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 28 Sep 2016 11:58:31 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <51FB7FE6-8D28-41A2-9B53-7033DB3BEE1E@muskala.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <51FB7FE6-8D28-41A2-9B53-7033DB3BEE1E@muskala.eu> Message-ID: <210e971c-639f-20a1-de0c-d6ecb4104ff7@ninenines.eu> On the "external tools": As far as my workflow is concerned, the Erlang shell is nearly never used. So starting the shell to then look for the function I want is not as efficient as just opening a man page. Not to mention the lack of search and navigation, plus the fact I'd need to open a separate shell just to keep the documentation on-screen while using the shell further. I've said it before, I don't think it's necessarily a bad idea to have interactive help in the shell, but it shouldn't replace other forms. Different formats are helpful to different people, and I think we should strive to provide as many options as possible to get to the documentation; not remove all of them just because of bad past decisions. On 09/28/2016 11:33 AM, Micha? Muska?a wrote: > While talking about Elixir documentation everybody seems to focus exclusively on the HTML docs. Surprisingly that's not the primary way of how I (and most of the people I know) interact with the documentation that Elixir provides - the primary way is the direct access to documentation from IEx. > > I guess that's in many ways similar to the access through man pages, but instead of using an external tool, it comes built-in right into the language itself. In the shell you can use the h/1 helper macro to access documentation on modules (h Kernel), all functions with a particular name (h Enum.reduce) or for a specific function with a particular arity (h Enum.reduce/3). Similarly there are helpers for accessing documentation on behaviours (b/1) and types (t/1). It works both for the standard library and the external packages. For those complaining about use of external tools - here you don't need any of them, only erlang/elixir - no lynx, no man, no browser. This has also a huge advantage of perfectly working offline - again for both the built-in modules as well as all the external dependencies in the exact same way. I cannot stress enough how valuable it is I can access documentation for all the modules I'm using in the same way. > > Here are some examples: > https://www.dropbox.com/s/0eleru83ya6oscg/Screenshot%202016-09-28%2011.29.10.png?dl=0 > https://www.dropbox.com/s/x8hg3qyfje0jpmc/Screenshot%202016-09-28%2011.29.53.png?dl=0 > https://www.dropbox.com/s/8c15as0cvu46gy0/Screenshot%202016-09-28%2011.31.27.png?dl=0 > https://www.dropbox.com/s/0xrqtuhjblixnjb/Screenshot%202016-09-28%2011.32.33.png?dl=0 > > Related to that is the ability to easily get the documentation programatically from the loaded code with the Code.get_docs/2 function. This allows various tools to access the documentation and present it directly in the code editor or whatever you can imagine. > > Micha?. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From vladdu55@REDACTED Wed Sep 28 12:22:23 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 28 Sep 2016 12:22:23 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <210e971c-639f-20a1-de0c-d6ecb4104ff7@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <51FB7FE6-8D28-41A2-9B53-7033DB3BEE1E@muskala.eu> <210e971c-639f-20a1-de0c-d6ecb4104ff7@ninenines.eu> Message-ID: On Wed, Sep 28, 2016 at 11:58 AM, Lo?c Hoguin wrote: > As far as my workflow is concerned, the Erlang shell is nearly never used. > So starting the shell to then look for the function I want is not as > efficient as just opening a man page. Not to mention the lack of search and > navigation, plus the fact I'd need to open a separate shell just to keep > the documentation on-screen while using the shell further. > I don't use the shell either, but I suppose that from a workflow POV, having a separate terminal tab with an erlang/elixir shell where one can enter "h something" is the same as having a terminal tab with bash where one enters "man something"? > I've said it before, I don't think it's necessarily a bad idea to have > interactive help in the shell, but it shouldn't replace other forms. > Different formats are helpful to different people, and I think we should > strive to provide as many options as possible to get to the documentation; > not remove all of them just because of bad past decisions. +1. Having an API for retrieving the documentation is something we should steal from Elixir, that opens even more options. The main hurdle would be that Erlang doc can be found both as edoc and as OTP xml... BTW, I don't have an Elixir installation available, but can it show even the docs for Erlang modules? regards, /Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Sep 28 12:40:47 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 28 Sep 2016 12:40:47 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <51FB7FE6-8D28-41A2-9B53-7033DB3BEE1E@muskala.eu> <210e971c-639f-20a1-de0c-d6ecb4104ff7@ninenines.eu> Message-ID: <979dc840-6e56-88e3-e2bc-015c65885ccb@ninenines.eu> On 09/28/2016 12:22 PM, Vlad Dumitrescu wrote: > > > On Wed, Sep 28, 2016 at 11:58 AM, Lo?c Hoguin > wrote: > > As far as my workflow is concerned, the Erlang shell is nearly never > used. So starting the shell to then look for the function I want is > not as efficient as just opening a man page. Not to mention the lack > of search and navigation, plus the fact I'd need to open a separate > shell just to keep the documentation on-screen while using the shell > further. > > > I don't use the shell either, but I suppose that from a workflow POV, > having a separate terminal tab with an erlang/elixir shell where one can > enter "h something" is the same as having a terminal tab with bash where > one enters "man something"? It would be if I kept the terminal around once I got whatever info I needed, which is rarely the case. I also occasionally need to "killall beam.smp". -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From jose.valim@REDACTED Wed Sep 28 16:38:53 2016 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 28 Sep 2016 16:38:53 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: Thanks Loic, some great feedback in there. Replies inline. > The lack of indentation alone makes the Elixir documentation unreadable. > Where do the functions start and end? This is much easier to figure out in > the Erlang documentation. > This has been improved in master: http://elixir-lang.org/docs/master/elixir/Kernel.html#functions (you may need a hard reload) > The huge vertical spacing everywhere makes it so that only about one > function and a half gets displayed on my screen at a time for equivalent > amount of information. The Erlang documentation has the double, 3 or 4 > functions. > We have a branch where we have reduced the amount of vertical spaces taken by functions. In some cases though it is more endemic to how the documentation was written: 4 paragraphs with 1 short-sentence each instead of 1 paragraph with 4 sentences. Those will take longer to be addressed. > For some reason all the specs and code examples have a bottom scrollbar > here even when no scrolling can be done. > Those have been fixed in master some time ago. I would definitely recommend a hard reload (Cmd+R) then. > The list of functions at the top is not very useful overall Just as a discussion point: we got a lot of positive feedback from it in the past. Specially from newcomers that want to have an overview of all existing functions in a module with a short description. I personally don't use it. > the list of functions on the left is better but in the case of Elixir when > I click "Functions" it scrolls the page for some reason; if I wanted to > stay where I was and just take a quick look if a function exists, there > goes my browsing. It also breaks the back/forward buttons for me (bad!). > Not to mention it's not clear that you can expand it. > Agreed. All of those points have already been listed as bugs. > I also have some concerns with the main Elixir site; the font and font > size make it hard to read. At least they got the font right in the function > reference. > The font-size has been increased thanks to a PR from Vlad. \o/ If anything looks suspicious, bug reports are also appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Sep 28 20:28:55 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 28 Sep 2016 20:28:55 +0200 Subject: [erlang-questions] Accessing the documentation at runtime Message-ID: Hi, Following the documentation discussion, and the details about how Elixir supports that as API, I wonder if we could (should?) support something similar for Erlang. My suggestion for the data to store is the xml source, parsed with xmerl into simple-form. For non-otp modules, there is an edoclet that can produce opt-like xml from edoc. I don't know what format elixir uses, but for consuming the OTP docs this feels the easiest. One way is to add an optional chunk to the beam files, storing the docs. A new compiler option would select that, similar to 'debug'. This would increase the size of the files significantly and possibly only few people will add the docs, resulting in an useless chunk, but if it gets used then all data is readily available. An alternative would be to deliver archives with the docs in separate files (a zip in myapp/doc?). What is needed then is an API to access that, "code:get_doc(Module|App)" feels like it would be enough. Thoughts? best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Sep 28 20:37:07 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 28 Sep 2016 20:37:07 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: References: Message-ID: I wouldn't put this in beam files. Tying documentation to compilation severely limits options for input files, or makes things a lot more complicated at best. I suggest separate files. One file really: priv/funcref.xml.gz It can be loaded with the application, if present. As such it wouldn't be a good place to put this in code server. On 09/28/2016 08:28 PM, Vlad Dumitrescu wrote: > Hi, > > Following the documentation discussion, and the details about how Elixir > supports that as API, I wonder if we could (should?) support something > similar for Erlang. > > My suggestion for the data to store is the xml source, parsed with xmerl > into simple-form. For non-otp modules, there is an edoclet that can > produce opt-like xml from edoc. I don't know what format elixir uses, > but for consuming the OTP docs this feels the easiest. > > One way is to add an optional chunk to the beam files, storing the docs. > A new compiler option would select that, similar to 'debug'. This would > increase the size of the files significantly and possibly only few > people will add the docs, resulting in an useless chunk, but if it gets > used then all data is readily available. > > An alternative would be to deliver archives with the docs in separate > files (a zip in myapp/doc?). > > What is needed then is an API to access that, "code:get_doc(Module|App)" > feels like it would be enough. > > Thoughts? > > best regards, > Vlad > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From erlang@REDACTED Wed Sep 28 21:44:21 2016 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 28 Sep 2016 21:44:21 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: References: Message-ID: Regarding an API It is not a coincidence that the HTML documentation for (say lists.erl) can be obtained by fetching the page http://erlang.org/doc/man/lists.html How about a REST interface to extract the parts of the documentation? For example http://erlang.org/doc/man/lists?type=xml would fetch the lists.xml (the documentation) http://erlang.org/doc/man/lists?type=erl (the code) and http://erlang.org/doc/man/lists?type=xml&func=append&arity=2 would fetch the documentation for lists:append/2 etc. If we *standardise* the interface then writing tools to present this in different ways should possible Cheers /Joe On Wed, Sep 28, 2016 at 8:28 PM, Vlad Dumitrescu wrote: > Hi, > > Following the documentation discussion, and the details about how Elixir > supports that as API, I wonder if we could (should?) support something > similar for Erlang. > > My suggestion for the data to store is the xml source, parsed with xmerl > into simple-form. For non-otp modules, there is an edoclet that can produce > opt-like xml from edoc. I don't know what format elixir uses, but for > consuming the OTP docs this feels the easiest. > > One way is to add an optional chunk to the beam files, storing the docs. A > new compiler option would select that, similar to 'debug'. This would > increase the size of the files significantly and possibly only few people > will add the docs, resulting in an useless chunk, but if it gets used then > all data is readily available. > > An alternative would be to deliver archives with the docs in separate files > (a zip in myapp/doc?). > > What is needed then is an API to access that, "code:get_doc(Module|App)" > feels like it would be enough. > > Thoughts? > > best regards, > Vlad > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From matthew.fitzpatrick6012@REDACTED Wed Sep 28 22:23:29 2016 From: matthew.fitzpatrick6012@REDACTED (Matthew Fitzpatrick) Date: Wed, 28 Sep 2016 15:23:29 -0500 Subject: [erlang-questions] Erlang 18.3 CentOS RPM/yum failing Message-ID: Not sure if anyone else is running into this, but it seems like it happened very recently guessing with yesterday's update. For myself at least, the yum installer for 18.3 is not working correctly anymore. It's breaking on dependency resolutions. My first question: Is this a "its my computer" problem? Is anyone else having issues here? I've tried on several different VM's and it seems like I'm in the clear there and this is a true issue, but I figured I would ask that first. And the follow-up, if people ARE having issues, who do we need to bug to fix the rpm's or how can we go about patching them up? Side Note: It seems like the erlang 19 packages are fine, if you run a vanilla `yum install erlang` np, its just when you specify `yum install erlang-18.3` you have issues with dependency resolution. Thanks, -Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Sep 28 22:28:00 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 28 Sep 2016 22:28:00 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: References: Message-ID: On Wed, Sep 28, 2016 at 9:44 PM, Joe Armstrong wrote: > Regarding an API > > It is not a coincidence that the HTML documentation for (say > lists.erl) can be obtained by fetching the page > http://erlang.org/doc/man/lists.html > > How about a REST interface to extract the parts of the documentation? > > For example > > http://erlang.org/doc/man/lists?type=xml > would fetch the lists.xml (the documentation) > > http://erlang.org/doc/man/lists?type=erl > (the code) > > and > http://erlang.org/doc/man/lists?type=xml&func=append&arity=2 > would fetch the documentation for lists:append/2 etc. > >From other comments on the documentation thread, there are many people that work offline, so accessing the documentation via internet is not useful. Even so, I would like to cache it locally, so it could be saved in an archive just as we said before. If we *standardise* the interface then writing tools to present this in > different ways should possible > We can standardise it just as well as to accessing the local file, how it gets there is another issue. Maybe it was downloaded, maybe it was installed, maybe it was built. BTW, we also want to make sure that we use the documentation matching the current version of the module, so we need the module's version attribute as key. regards, Vlad > > On Wed, Sep 28, 2016 at 8:28 PM, Vlad Dumitrescu > wrote: > > Hi, > > > > Following the documentation discussion, and the details about how Elixir > > supports that as API, I wonder if we could (should?) support something > > similar for Erlang. > > > > My suggestion for the data to store is the xml source, parsed with xmerl > > into simple-form. For non-otp modules, there is an edoclet that can > produce > > opt-like xml from edoc. I don't know what format elixir uses, but for > > consuming the OTP docs this feels the easiest. > > > > One way is to add an optional chunk to the beam files, storing the docs. > A > > new compiler option would select that, similar to 'debug'. This would > > increase the size of the files significantly and possibly only few people > > will add the docs, resulting in an useless chunk, but if it gets used > then > > all data is readily available. > > > > An alternative would be to deliver archives with the docs in separate > files > > (a zip in myapp/doc?). > > > > What is needed then is an API to access that, "code:get_doc(Module|App)" > > feels like it would be enough. > > > > Thoughts? > > > > best regards, > > Vlad > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zzantozz@REDACTED Wed Sep 28 22:50:58 2016 From: zzantozz@REDACTED (Ryan Stewart) Date: Wed, 28 Sep 2016 20:50:58 +0000 Subject: [erlang-questions] Erlang 18.3 CentOS RPM/yum failing In-Reply-To: References: Message-ID: The erlang package is a metapackage that pulls in a bunch of erlang-* packages. It looks like new erlang 19 packages have obsoleted some of those erlang 18.3 packages, so yum is trying to get the newer packages to replace the obsoleted one without realizing that all of these packages ought to be kept at the same version. Try "yum install erlang-18.3 --setopt=obsoletes=0", and see what you get. On Wed, Sep 28, 2016 at 3:23 PM Matthew Fitzpatrick < matthew.fitzpatrick6012@REDACTED> wrote: > Not sure if anyone else is running into this, but it seems like it > happened very recently guessing with yesterday's update. For myself at > least, the yum installer for 18.3 is not working correctly anymore. It's > breaking on dependency resolutions. > > My first question: Is this a "its my computer" problem? Is anyone else > having issues here? I've tried on several different VM's and it seems like > I'm in the clear there and this is a true issue, but I figured I would ask > that first. > > And the follow-up, if people ARE having issues, who do we need to bug to > fix the rpm's or how can we go about patching them up? > > Side Note: It seems like the erlang 19 packages are fine, if you run a > vanilla `yum install erlang` np, its just when you specify `yum install > erlang-18.3` you have issues with dependency resolution. > > Thanks, > -Matthew > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Sep 28 22:57:08 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 28 Sep 2016 22:57:08 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: Okay, I gave it a shot. Made some small changes to the XSL and to the CSS. Nothing too drastic, on purpose. http://download.erlide.org/otp/lists.html There are still many small details to fix, so it's the general feeling that I want to share, not the details. Each part can be styled independently, something impossible before. We can add better handling of different viewport widths (for example, on a wide monitor we could show the examples in a separate column). best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From zzantozz@REDACTED Wed Sep 28 22:58:00 2016 From: zzantozz@REDACTED (Ryan Stewart) Date: Wed, 28 Sep 2016 20:58:00 +0000 Subject: [erlang-questions] Erlang 18.3 CentOS RPM/yum failing In-Reply-To: References: Message-ID: Oh, and keep in mind that yum install/remove can leave vestigial remnants of apps behind in /usr/lib64/erlang/lib, which can cause havoc when you downgrade. Specifically, the asn1 and ic apps seem to leave stuff behind. If you've installed 19, then removed it to install 18.3, you should nuke /usr/lib64/erlang/lib from orbit before you do. On Wed, Sep 28, 2016 at 3:51 PM Ryan Stewart wrote: > The erlang package is a metapackage that pulls in a bunch of erlang-* > packages. It looks like new erlang 19 packages have obsoleted some of those > erlang 18.3 packages, so yum is trying to get the newer packages to replace > the obsoleted one without realizing that all of these packages ought to be > kept at the same version. Try "yum install erlang-18.3 > --setopt=obsoletes=0", and see what you get. > > On Wed, Sep 28, 2016 at 3:23 PM Matthew Fitzpatrick < > matthew.fitzpatrick6012@REDACTED> wrote: > >> Not sure if anyone else is running into this, but it seems like it >> happened very recently guessing with yesterday's update. For myself at >> least, the yum installer for 18.3 is not working correctly anymore. It's >> breaking on dependency resolutions. >> >> My first question: Is this a "its my computer" problem? Is anyone else >> having issues here? I've tried on several different VM's and it seems like >> I'm in the clear there and this is a true issue, but I figured I would ask >> that first. >> >> And the follow-up, if people ARE having issues, who do we need to bug to >> fix the rpm's or how can we go about patching them up? >> >> Side Note: It seems like the erlang 19 packages are fine, if you run a >> vanilla `yum install erlang` np, its just when you specify `yum install >> erlang-18.3` you have issues with dependency resolution. >> >> Thanks, >> -Matthew >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Thu Sep 29 00:05:10 2016 From: lloyd@REDACTED (lloyd@REDACTED) Date: Wed, 28 Sep 2016 18:05:10 -0400 (EDT) Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: <1475100310.278818739@apps.rackspace.com> Nice step forward, Vlad! How do you suggest that we handle some of the other issues raised on the list: -- offline access? -- optional output formats; e.g. pdf, etc.? -- updates, corrections, etc.? Tip of the hat, Lloyd -----Original Message----- From: "Vlad Dumitrescu" Sent: Wednesday, September 28, 2016 4:57pm To: "erlang-questions" Subject: Re: [erlang-questions] Erlang documentation -- a modest proposal _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions Okay, I gave it a shot. Made some small changes to the XSL and to the CSS. Nothing too drastic, on purpose. http://download.erlide.org/otp/lists.html There are still many small details to fix, so it's the general feeling that I want to share, not the details. Each part can be styled independently, something impossible before. We can add better handling of different viewport widths (for example, on a wide monitor we could show the examples in a separate column). best regards, Vlad From ok@REDACTED Thu Sep 29 01:28:05 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 29 Sep 2016 12:28:05 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> Message-ID: <147ccb11-7629-36c2-1a44-212050301399@cs.otago.ac.nz> On 28/09/16 9:55 PM, Vlad Dumitrescu wrote: >>[I was very unhappy about the Elixir Kernel.html page.] > I don't know what Kenneth wanted to highlight with the Elixir docs, but > I don't think that he meant the exact presentation. He certainly praised "layout". I didn't find the structure especially helpful either. The distinction between types and functions and macros is an *IMPLEMENTOR*'s distinction, not a *USER*'s distinction. Eiffel gets this right: what is the distinction, *for a user*, between a named constant, a variable that is exported from a class (such variables can only be modified by the class's own code), and a feature (method) with no parameters? There isn't any. What I need is - an application or module overview - a pointer to separate example modules or scripts (complete things) test cases and maybe the source code - a list of topics (table-of-contents) - within topics - an overview of the topic - a pointer to examples (code fragments) relating to that topic test cases and maybe the source code - a list of subtopics (table-of-contents) - within subtopics - name - syntax (type definition, function interface, &c) - semantics (what the alternatives for a type mean, what is the function supposed to compute) - pragmatics (when did it become available, has it been superseded and if so by what, are there any performance or security issues I should know about) - a pointer to examples and test cases and maybe the source code. The *last* thing I need to know is whether something is a type, a constant, a function, a macro &c. In all honestly, organising things by Types Functions Macros is like the bad old days of Pascal programs where you had to put all the labels, then all the constants, then all the types, then all the variables, then all the procedures and functions, meaning that you had to rip semantically related things apart on implementation grounds. > I can only see one major difference: the function list for a module is > inline (elixir) instead of in the sidebar (erlang). Which one is best? > I've heard people arguing for both. They are both wrong. They are alphabetic rather than topical. This has, for example, the *ABSURD* consequence that binary_to_term/1 term_to_binary/1 are far from each other in the erlang module's documentation. Similarly, the weeping members of the integer_to_list/1, list_to_integer/1, float_to_list/1, list_to_float/1 family are cruelly separated. More precisely, they are both half right. If I *know* which function I want, the alphabetic list helps me find it quickly. But if I only know what the function is *about*, the alphabetic list helps very little. The actual descriptions of semantically related functions should be physically close in the body of the text so that when I am looking at one, a related one is just a glance away. > > IMHO, presenting reference documentation so that everybody is pleased is > extremely difficult, because people use the docs in many different ways. > Different layout and information detail are most useful for beginners > (that browse to see what's available and might learn something unrelated > in the process) > than for people that mostly know what they look for (that need fast > access to some detail, often from the shell). If there's anyone here who is NOT a beginner, it's surely Joe Armstrong. Yet he has made the point that in each module that he uses, there is a small number of functions that he uses a lot, and the rest which he uses very seldom. That means that *sometimes* when he looks at dict *sometimes* he will be approaching it as an expert refreshing his memory about something and *sometimes* he will be approaching it as a beginning looking for information about a function he uses so rarely he can't even recall its name. Every release there seems to be new stuff in the erlang: module, so every release I am a beginner again about *something* useful in that module. > It's also difficult to create a presentation that works for a full-blown > browser as well as for lynx. It doesn't have to be the same HTML file does it? HTML-optimised-for-Lynx-or-w3m-or-Emacs-w3 and HTML-optimised-for-Firefox-on-a-huge-screen and HTML-optimised-for-a-Windows-phone really need to be three different versions. ? I'm not referring to the visuals, but the > module and function index, which is > huge and needs to be folded. I can't come up with a way to do that > without javascript. But I don't *want* "huge" function and module indices in my pages all the time. (Hint: "huge" lists are hard to find things in.) There's one thing I do heartily approve of in the Elixir pages, which is that there is a very simple way to get rid of the navbar. In fact I'm personally quite happy to have - a module list in one tab - a topic (NOT function!) list in another tab - the main text scrolled to the current topic in another tab because quite often when I click on a navbar link what I want is to see another topic *as well* (in a new tab), not *instead* of the one I'm looking at. > BTW, it's trivial (see comment above regarding html friendliness, > though) to make the erlang docs look more like elixir's while keeping > the good parts. See picture :-) > https://www.dropbox.com/s/jqpqpcimv3qxdce/e0.png?dl=0 Problem 1: the structure is Types: [ Example: ] The word "Types:" is pointless. I can *see* that they are types. Problem 2: if anything should be highlighted here, it is the function name. If the function name is bold. there's no need for the , and my eye is directed to the most salient piece of information. Problem 3: the font used for code in the and and the font used for code in the are not the same font. Worse still, the font used for the expression in the and the font used for the result are not the same font. (Or more precisely, they may be different weights of the same font.) Problem 4: the font used for code in the does not have the same x-height as the font used for ordinary text. The code font is markedly smaller. Problem 5: the font used for code in the and for the result in <...example> are markedly fainter than the other fonts. I could go on. But this is the fundamental problem with trying to do fancy typography in HTML. It is very very hard to make it look good. If you want fancy typography that actually looks good, PDF is the only game in town. HTML is just the wrong tool for that job. HTML is great for when you have no idea what the user's screen resolution is, very little idea what fonts they have, how big their browser window is, whether they can discriminate colours (and in our fairly small department, two of my colleagues are red-green colour-blind, making many syntax colouring themes worse than useless for them), whether they can tolerate small text, .... From ok@REDACTED Thu Sep 29 01:39:35 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 29 Sep 2016 12:39:35 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <38AD0A90-B53E-4F52-AD73-7E15F9C27375@gmail.com> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <38AD0A90-B53E-4F52-AD73-7E15F9C27375@gmail.com> Message-ID: On 28/09/16 10:22 PM, Anthony Ramine wrote: > > So why do you hardwrap all your emails by hand to 50 columns? You are wasting my real screen estate. Do you hate me? :( E-mail is not documentation. As to why I do it, your unwrapped lines are truncated in my MUA. > > Syntax colouring of examples usually need JS because otherwise the HTML markup to be downloaded becomes really heavy. Syntax colouring is something we're better off without. Why? Because it makes *irrelevant* distinctions that are already apparent in the text, at the price of reducing the contrast, thereby making the code less readable. If syntax colouring were easily controlled by the end-user, that might be tolerable. From n.oxyde@REDACTED Thu Sep 29 01:49:36 2016 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 29 Sep 2016 01:49:36 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <38AD0A90-B53E-4F52-AD73-7E15F9C27375@gmail.com> Message-ID: Replied inline. > Le 29 sept. 2016 ? 01:39, Richard A. O'Keefe a ?crit : > > > > On 28/09/16 10:22 PM, Anthony Ramine wrote: >> >> So why do you hardwrap all your emails by hand to 50 columns? You are wasting my real screen estate. Do you hate me? :( > > E-mail is not documentation. It's text. Whatever brand of text, long lines are never readable. > As to why I do it, your unwrapped lines are truncated in my MUA. Maybe you should use a more modern MUA that actually handles quoted-printable correctly? There is nothing wrong with my MUA nor what I send. >> Syntax colouring of examples usually need JS because otherwise > > the HTML markup to be downloaded becomes really heavy. Seems like your MUA cannot quote properly. :( Maybe update it? > Syntax colouring is something we're better off without. > > Why? Because it makes *irrelevant* distinctions that are > already apparent in the text, at the price of reducing the > contrast, thereby making the code less readable. > > If syntax colouring were easily controlled by the end-user, > that might be tolerable. What about your students? Don't they like syntax colouring? Maybe you should just consider you are not a representative part of what developers in our current age do? I'm grumpy sometimes at what my brethren do, but I realise sometimes multiple opinions must coexist. For syntax colouring to be easily controlled anyway, the markup would have to not include it, and thus you would still need to rely on JS. From n.oxyde@REDACTED Thu Sep 29 01:51:03 2016 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 29 Sep 2016 01:51:03 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <147ccb11-7629-36c2-1a44-212050301399@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <147ccb11-7629-36c2-1a44-212050301399@cs.otago.ac.nz> Message-ID: <57BC0625-9E2A-4788-90F2-BDD05DB10ACF@gmail.com> Replied below because I'm a lunatic. > Le 29 sept. 2016 ? 01:28, Richard A. O'Keefe a ?crit : > > It doesn't have to be the same HTML file does it? > HTML-optimised-for-Lynx-or-w3m-or-Emacs-w3 and > HTML-optimised-for-Firefox-on-a-huge-screen and > HTML-optimised-for-a-Windows-phone > really need to be three different versions. I'm 100% sure Tim Berners-Lee will never, ever wish for multiple HTML files for a single resource. From ok@REDACTED Thu Sep 29 01:56:53 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 29 Sep 2016 12:56:53 +1300 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: References: Message-ID: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> On 29/09/16 7:28 AM, Vlad Dumitrescu wrote: > Hi, > > Following the documentation discussion, and the details about how Elixir > supports that as API, I wonder if we could (should?) support something > similar for Erlang. Quintus Prolog did this back in the 1980s. The manuals were originally written in Scribe, then switched over to LaTeX, using very simple markup. They were automatically converted to plain text files, one per section, and - REPL "take me to this section" - REPL "take me to this topic" - Emacs "take me to the documentation for this" - Emacs "navigate within documentation" worked from that. I believe SWI Prolog does something similar. R has its own markup "Rd" and R CMD Rdconv converts Rd to plain text, LaTeX, HTML, or extracts examples so R can run them. R CMD Rd2pdf converts Rd (listed files, or in a directory) to PDF. R CMD Rd2txt converts Rd to plain text This means that it's possible to write a 'man' equivalent for R if you know where the Rd files are. It also supports help(topic, package = NULL, lib.loc = NULL, verbose = getOption("verbose"), try.all.packages = getOption("help.try.all.packages"), help_type = getOption("help_type")) help.search(pattern, fields = c("alias", "concept", "title"), apropos, keyword, whatis, ignore.case = TRUE, package = NULL, lib.loc = NULL, help.db = getOption("help.db"), verbose = getOption("verbose"), rebuild = FALSE, agrep = NULL, use_UTF8 = FALSE, types = getOption("help.search.types")) ??pattern field??pattern ?word in the REPL, and of course help() and help.search() may be called from code. Note that a good way to store XML is to use a compressor like XMill. From lloyd@REDACTED Thu Sep 29 02:34:35 2016 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Wed, 28 Sep 2016 20:34:35 -0400 Subject: [erlang-questions] The Problem with Linux Kernel Documentation, and How We're Fixing it - Samsung Open Source Group Blog Message-ID: <32E06F26-7C4F-4A41-8790-C725358AC70A@writersglen.com> No doubt many of you have seen this. But we're not alone in struggling with the issue of documentation. I wonder if there are any take-always from the large Linux community. https://blogs.s-osg.org/problem-linux-kernel-documentation-fixing/ All the best, LRP Sent from my iPad From erlang@REDACTED Thu Sep 29 08:07:16 2016 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 29 Sep 2016 08:07:16 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: On Wed, Sep 28, 2016 at 10:57 PM, Vlad Dumitrescu wrote: > Okay, I gave it a shot. Made some small changes to the XSL and to the CSS. > Nothing too drastic, on purpose. > > http://download.erlide.org/otp/lists.html Nice - I'd like a few change (which I'll try to do myself) - change the ordering (it's alphabetic) - I'd like a 'best of' (or essential functions first) - the minimal set you should know about - fold away the details - I'd like to see only the name and one-line header possible the spec and examples should appear in a hover box (and yes I don't mind if it uses JS) The goal of these changes is to pack more relevant information into my limited screen space /Joe > > There are still many small details to fix, so it's the general feeling that > I want to share, not the details. Each part can be styled independently, > something impossible before. We can add better handling of different > viewport widths (for example, on a wide monitor we could show the examples > in a separate column). > > best regards, > Vlad > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From vladdu55@REDACTED Thu Sep 29 09:11:42 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 29 Sep 2016 09:11:42 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: <147ccb11-7629-36c2-1a44-212050301399@cs.otago.ac.nz> References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <147ccb11-7629-36c2-1a44-212050301399@cs.otago.ac.nz> Message-ID: On Thu, Sep 29, 2016 at 1:28 AM, Richard A. O'Keefe wrote: > > On 28/09/16 9:55 PM, Vlad Dumitrescu wrote: > >>[I was very unhappy about the Elixir Kernel.html page.] > > I don't know what Kenneth wanted to highlight with the Elixir docs, but >> I don't think that he meant the exact presentation. >> > > He certainly praised "layout". > Yes, but layout (according to my understanding of the term) doesn't have anything to do with use colors or fonts. Just the placement in page. I didn't find the structure especially helpful either. > The distinction between types and functions and macros > is an *IMPLEMENTOR*'s distinction, not a *USER*'s distinction. > I will comment here instead of below because the text is very long. There are important and valuable things there to be noted and taken into consideration, but most of them are about the _content_ of the documentation. What I can do right now, with relatively little effort, is take the current sources and try to present them in a slightly better way, for some definition of 'better'. At the moment, I only did a few small changes, which I hope showed that improvement can be done even without touching the sources. Restructuring the whole documentation, adding marking to allow sorting and indexing by different keys and grouping by semantic relatedness, catering for both "beginner" and "expert" users; all without using javascript or any more advanced features (so that even browsers that can't handle them can be used) is a huge undertaking that is a task for the future. Regarding how Joe is using the docs. How can one provide a static HTML that is able to guess which mode the user is in right now ('beginner' or 'expert')? > HTML is great for when you have no idea what the user's > screen resolution is, very little idea what fonts they > have, how big their browser window is, whether they can > discriminate colours (and in our fairly small department, > two of my colleagues are red-green colour-blind, making > many syntax colouring themes worse than useless for them), > whether they can tolerate small text, .... On the web, this is exactly the situation. We don't know anything about the users' situation. At best, we can get statistics about some of these things. What is different in our situation? What more information do we have about the users? Except that they are Erlang users, but that doesn't help much. For typographically wonderful documentation, there is the PDF version. For the web we can implement things that are impossible with PDF, namely interactivity (sorting, grouping, filtering, theming), for users that can and want to use a modern browser and javascript. Otherwise one can target just one group at a time. best regards, Vlad > Eiffel gets this right: what is the distinction, *for a user*, > between a named constant, a variable that is exported from a > class (such variables can only be modified by the class's own > code), and a feature (method) with no parameters? There isn't > any. > > What I need is > - an application or module overview > - a pointer to separate example modules or scripts (complete things) > test cases and maybe the source code > - a list of topics (table-of-contents) > - within topics > - an overview of the topic > - a pointer to examples (code fragments) relating to that topic > test cases and maybe the source code > - a list of subtopics (table-of-contents) > - within subtopics > - name > - syntax (type definition, function interface, &c) > - semantics (what the alternatives for a type mean, what > is the function supposed to compute) > - pragmatics (when did it become available, has it been > superseded and if so by what, are there any performance > or security issues I should know about) > - a pointer to examples and test cases and maybe the source code. > > The *last* thing I need to know is whether something is a > type, a constant, a function, a macro &c. > > In all honestly, organising things by Types Functions Macros > is like the bad old days of Pascal programs where you had to > put all the labels, then all the constants, then all the > types, then all the variables, then all the procedures and > functions, meaning that you had to rip semantically related > things apart on implementation grounds. > > I can only see one major difference: the function list for a module is >> inline (elixir) instead of in the sidebar (erlang). Which one is best? >> I've heard people arguing for both. >> > > They are both wrong. They are alphabetic rather than topical. > This has, for example, the *ABSURD* consequence that > binary_to_term/1 > term_to_binary/1 > are far from each other in the erlang module's documentation. > Similarly, the weeping members of the integer_to_list/1, > list_to_integer/1, float_to_list/1, list_to_float/1 family > are cruelly separated. > > More precisely, they are both half right. If I *know* which > function I want, the alphabetic list helps me find it quickly. > But if I only know what the function is *about*, the alphabetic > list helps very little. > > The actual descriptions of semantically related functions should > be physically close in the body of the text so that when I am > looking at one, a related one is just a glance away. > > >> IMHO, presenting reference documentation so that everybody is pleased is >> extremely difficult, because people use the docs in many different ways. >> Different layout and information detail are most useful for beginners >> (that browse to see what's available and might learn something unrelated >> in the process) >> than for people that mostly know what they look for (that need fast >> access to some detail, often from the shell). >> > > If there's anyone here who is NOT a beginner, it's surely Joe > Armstrong. Yet he has made the point that in each module that > he uses, there is a small number of functions that he uses a lot, > and the rest which he uses very seldom. That means that > *sometimes* when he looks at dict *sometimes* he will be approaching > it as an expert refreshing his memory about something and > *sometimes* he will be approaching it as a beginning looking for > information about a function he uses so rarely he can't even recall > its name. > > Every release there seems to be new stuff in the erlang: module, > so every release I am a beginner again about *something* useful > in that module. > > It's also difficult to create a presentation that works for a full-blown >> browser as well as for lynx. >> > > It doesn't have to be the same HTML file does it? > HTML-optimised-for-Lynx-or-w3m-or-Emacs-w3 and > HTML-optimised-for-Firefox-on-a-huge-screen and > HTML-optimised-for-a-Windows-phone > really need to be three different versions. > > ? I'm not referring to the visuals, but the > >> module and function index, which is >> huge and needs to be folded. I can't come up with a way to do that >> without javascript. >> > > But I don't *want* "huge" function and module indices > in my pages all the time. (Hint: "huge" lists are hard > to find things in.) There's one thing I do heartily > approve of in the Elixir pages, which is that there is a > very simple way to get rid of the navbar. In fact I'm > personally quite happy to have > - a module list in one tab > - a topic (NOT function!) list in another tab > - the main text scrolled to the current topic in another tab > because quite often when I click on a navbar link what I > want is to see another topic *as well* (in a new tab), > not *instead* of the one I'm looking at. > > BTW, it's trivial (see comment above regarding html friendliness, >> though) to make the erlang docs look more like elixir's while keeping >> the good parts. See picture :-) >> https://www.dropbox.com/s/jqpqpcimv3qxdce/e0.png?dl=0 >> > > Problem 1: the structure is > > Types: > > > > > [ Example: > ] > > The word "Types:" is pointless. I can *see* that they are types. > > Problem 2: if anything should be highlighted here, it is the > function name. If the function name is bold. there's no need > for the , and my eye is directed to the > most salient piece of information. > > Problem 3: the font used for code in the > and and the font used for code > in the are not the same font. Worse still, the > font used for the expression in the example> and the font used for the result are not the same > font. (Or more precisely, they may be different weights of > the same font.) > > Problem 4: the font used for code in the does not have > the same x-height as the font used for ordinary text. The > code font is markedly smaller. > > Problem 5: the font used for code in the and for the > result in <...example> are markedly fainter than the other > fonts. > > I could go on. > > But this is the fundamental problem with trying to do fancy > typography in HTML. It is very very hard to make it look good. > If you want fancy typography that actually looks good, > PDF is the only game in town. > > HTML is just the wrong tool for that job. > > HTML is great for when you have no idea what the user's > screen resolution is, very little idea what fonts they > have, how big their browser window is, whether they can > discriminate colours (and in our fairly small department, > two of my colleagues are red-green colour-blind, making > many syntax colouring themes worse than useless for them), > whether they can tolerate small text, .... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Thu Sep 29 09:19:53 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 29 Sep 2016 09:19:53 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: On Thu, Sep 29, 2016 at 8:07 AM, Joe Armstrong wrote: > On Wed, Sep 28, 2016 at 10:57 PM, Vlad Dumitrescu > wrote: > > Okay, I gave it a shot. Made some small changes to the XSL and to the > CSS. > > Nothing too drastic, on purpose. > > > > http://download.erlide.org/otp/lists.html > > Nice - I'd like a few change (which I'll try to do myself) > > - change the ordering (it's alphabetic) - I'd like a 'best of' (or > essential functions first) - the minimal set you should know about > - fold away the details - I'd like to see only the name and one-line > header > possible the spec and examples should appear in a hover box > (and yes I don't mind if it uses JS) > > The goal of these changes is to pack more relevant information into my > limited screen space > Yes, this is just a quick thing I did last night. It can be improved in many ways. The ordering is part of the content, not the presentation, and it's certainly a big job. Besides, some users might like the alphabetical order... so I think that the best way would be to mark up the source, adding different indices and groupings, and linking to semantically related functions. Then the user could choose how the data should be presented, depending on the current needs. The folding is relatively easy to achieve. My example has no JS on purpose. There are multiple ways to solve problems. As with anything else, it's a matter of how much time one can invest in implementing them. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.behnke@REDACTED Thu Sep 29 09:43:00 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Thu, 29 Sep 2016 09:43:00 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> References: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> Message-ID: <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> Hi all, the discussion leaves me with the impression that everybody has his or her own method of accessing the documentation. And even that may change according to circumstances. I think a solution should be modular to cater to a wide range of personal preferences and situational restrictions. Joe's suggestion of a REST engine, that can provide the documentation in the format of your choice, does not automatically mean it only works online. Lets write a small doc-engine that can do all that. It should run as a self contained program on your local machine. And erlang.org may need the full phoenix+nginx-proxy+hardware-loadbalancer (or whatever) to support the traffic (is that what CDNs are for?). But erlide or emacs or the erl-shell could all access this locally. The user can choose to configure the localhost, the work group server or erlang.org as the source machine. The documentation should not be part of the beam file. My production servers don't need documentation. On the other hand, a location convention for documentation placement for an app and module would be very helpful. This would allow the doc-server to be pointed to a OTP source drop and get additional locations to my personal app library, so that I can access all documentation through the same mechanism. I do not understand why there is a discussion on the html layout in the days of reactive design. Format the html for a lynx or similar for use when no javascript is available. Do proper _logical_ markup (function-definition, example, etc.) for CSS consumption. Using the REST server concept it would be easy to add an option to use personalized CSS URLs. This would make catering to special accessibility needs (color blind, hate of syntax highlighting, etc.) a lot easier. Even generating static man pages would be straight forward provided there is a erlDocREST2man script which will walk the documentation and write out the files and packages for installation with an (almost) minimal erlang system mfg lutz Am 29.09.2016 um 01:56 schrieb Richard A. O'Keefe: > > > On 29/09/16 7:28 AM, Vlad Dumitrescu wrote: >> Hi, >> >> Following the documentation discussion, and the details about how Elixir >> supports that as API, I wonder if we could (should?) support something >> similar for Erlang. > > Quintus Prolog did this back in the 1980s. > The manuals were originally written in Scribe, > then switched over to LaTeX, using very simple > markup. > They were automatically converted to plain text > files, one per section, and > - REPL "take me to this section" > - REPL "take me to this topic" > - Emacs "take me to the documentation for this" > - Emacs "navigate within documentation" > worked from that. > > I believe SWI Prolog does something similar. > > R has its own markup "Rd" and > R CMD Rdconv > converts Rd to plain text, LaTeX, HTML, > or extracts examples so R can run them. > R CMD Rd2pdf > converts Rd (listed files, or in a directory) > to PDF. > R CMD Rd2txt > converts Rd to plain text > This means that it's possible to write a 'man' equivalent > for R if you know where the Rd files are. It also supports > > help(topic, package = NULL, lib.loc = NULL, > verbose = getOption("verbose"), > try.all.packages = getOption("help.try.all.packages"), > help_type = getOption("help_type")) > help.search(pattern, fields = c("alias", "concept", "title"), > apropos, keyword, whatis, ignore.case = TRUE, > package = NULL, lib.loc = NULL, > help.db = getOption("help.db"), > verbose = getOption("verbose"), > rebuild = FALSE, agrep = NULL, use_UTF8 = FALSE, > types = getOption("help.search.types")) > ??pattern > field??pattern > ?word > > in the REPL, and of course help() and help.search() > may be called from code. > > Note that a good way to store XML is to use a compressor like XMill. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5006 bytes Desc: S/MIME Cryptographic Signature URL: From vladdu55@REDACTED Thu Sep 29 11:03:05 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 29 Sep 2016 11:03:05 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> References: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> Message-ID: Hi! On Thu, Sep 29, 2016 at 9:43 AM, Lutz Behnke wrote: > > the discussion leaves me with the impression that everybody has his or her > own method of accessing the documentation. And even that may change > according to circumstances. I think a solution should be modular to cater > to a wide range of personal preferences and situational restrictions. > > Joe's suggestion of a REST engine, that can provide the documentation in > the format of your choice, does not automatically mean it only works > online. Lets write a small doc-engine that can do all that. It should run > as a self contained program on your local machine. And erlang.org may > need the full phoenix+nginx-proxy+hardware-loadbalancer (or whatever) to > support the traffic (is that what CDNs are for?). But erlide or emacs or > the erl-shell could all access this locally. > The user can choose to configure the localhost, the work group server or > erlang.org as the source machine. > Several (and in increasing numbers) editors and IDEs have started using the concept of "language servers" that are standalone servers providing information about source code (code completion, context documentation, etc). There is a protocol specified at https://github.com/Microsof t/language-server-protocol. Serving documentation like we discussed is not yet part of the protocol, but I created an issue to see what they think about it. I have started working on implementing such a server for (and in) Erlang. It's very prototype-y at the moment. Even if the standard protocol won't support this case, it would be easy to extend it. I do not understand why there is a discussion on the html layout in the > days of reactive design. Format the html for a lynx or similar for use when > no javascript is available. Do proper _logical_ markup > (function-definition, example, etc.) for CSS consumption. I believe it's because we're not web developers :-) The logical markup is what I set up to do. > Using the REST server concept it would be easy to add an option to use > personalized CSS URLs. This would make catering to special accessibility > needs (color blind, hate of syntax highlighting, etc.) a lot easier. > That is an interesting idea. For the record, this can be done without any REST server, just make sure that whichever method is used to retrieve the docs accepts parameters and can do the processing. best regards, Vlad > Even generating static man pages would be straight forward provided there > is a erlDocREST2man script which will walk the documentation and write out > the files and packages for installation with an (almost) minimal erlang > system > > mfg lutz > > Am 29.09.2016 um 01:56 schrieb Richard A. O'Keefe: > >> >> >> On 29/09/16 7:28 AM, Vlad Dumitrescu wrote: >> >>> Hi, >>> >>> Following the documentation discussion, and the details about how Elixir >>> supports that as API, I wonder if we could (should?) support something >>> similar for Erlang. >>> >> >> Quintus Prolog did this back in the 1980s. >> The manuals were originally written in Scribe, >> then switched over to LaTeX, using very simple >> markup. >> They were automatically converted to plain text >> files, one per section, and >> - REPL "take me to this section" >> - REPL "take me to this topic" >> - Emacs "take me to the documentation for this" >> - Emacs "navigate within documentation" >> worked from that. >> >> I believe SWI Prolog does something similar. >> >> R has its own markup "Rd" and >> R CMD Rdconv >> converts Rd to plain text, LaTeX, HTML, >> or extracts examples so R can run them. >> R CMD Rd2pdf >> converts Rd (listed files, or in a directory) >> to PDF. >> R CMD Rd2txt >> converts Rd to plain text >> This means that it's possible to write a 'man' equivalent >> for R if you know where the Rd files are. It also supports >> >> help(topic, package = NULL, lib.loc = NULL, >> verbose = getOption("verbose"), >> try.all.packages = getOption("help.try.all.packages"), >> help_type = getOption("help_type")) >> help.search(pattern, fields = c("alias", "concept", "title"), >> apropos, keyword, whatis, ignore.case = TRUE, >> package = NULL, lib.loc = NULL, >> help.db = getOption("help.db"), >> verbose = getOption("verbose"), >> rebuild = FALSE, agrep = NULL, use_UTF8 = FALSE, >> types = getOption("help.search.types")) >> ??pattern >> field??pattern >> ?word >> >> in the REPL, and of course help() and help.search() >> may be called from code. >> >> Note that a good way to store XML is to use a compressor like XMill. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Lutz Behnke > Hochschule f?r Angewandte Wissenschaften Hamburg, > Labor f?r Allgemeine Informatik, > > phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED > fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage > Berliner Tor 7, 20099 Hamburg, Germany > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Sep 29 12:22:29 2016 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 29 Sep 2016 12:22:29 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> References: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> Message-ID: On Thu, Sep 29, 2016 at 9:43 AM, Lutz Behnke wrote: > Hi all, > > the discussion leaves me with the impression that everybody has his or her > own method of accessing the documentation. And even that may change > according to circumstances. I think a solution should be modular to cater to > a wide range of personal preferences and situational restrictions. > > Joe's suggestion of a REST engine, that can provide the documentation in the > format of your choice, does not automatically mean it only works online. Not really - whatever you do on-line can easily be achieved with a local webserver which can be packaged with the rest of the system > Lets write a small doc-engine that can do all that. It should run as a self > contained program on your local machine. Yes - but it could use the same REST interface as above /Joe > And erlang.org may need the full > phoenix+nginx-proxy+hardware-loadbalancer (or whatever) to support the > traffic (is that what CDNs are for?). But erlide or emacs or the erl-shell > could all access this locally. > The user can choose to configure the localhost, the work group server or > erlang.org as the source machine. > > The documentation should not be part of the beam file. My production servers > don't need documentation. On the other hand, a location convention for > documentation placement for an app and module would be very helpful. This > would allow the doc-server to be pointed to a OTP source drop and get > additional locations to my personal app library, so that I can access all > documentation through the same mechanism. > > I do not understand why there is a discussion on the html layout in the days > of reactive design. Format the html for a lynx or similar for use when no > javascript is available. Do proper _logical_ markup (function-definition, > example, etc.) for CSS consumption. Using the REST server concept it would > be easy to add an option to use personalized CSS URLs. This would make > catering to special accessibility needs (color blind, hate of syntax > highlighting, etc.) a lot easier. > > Even generating static man pages would be straight forward provided there is > a erlDocREST2man script which will walk the documentation and write out the > files and packages for installation with an (almost) minimal erlang system > > mfg lutz > > > Am 29.09.2016 um 01:56 schrieb Richard A. O'Keefe: >> >> >> >> On 29/09/16 7:28 AM, Vlad Dumitrescu wrote: >>> >>> Hi, >>> >>> Following the documentation discussion, and the details about how Elixir >>> supports that as API, I wonder if we could (should?) support something >>> similar for Erlang. >> >> >> Quintus Prolog did this back in the 1980s. >> The manuals were originally written in Scribe, >> then switched over to LaTeX, using very simple >> markup. >> They were automatically converted to plain text >> files, one per section, and >> - REPL "take me to this section" >> - REPL "take me to this topic" >> - Emacs "take me to the documentation for this" >> - Emacs "navigate within documentation" >> worked from that. >> >> I believe SWI Prolog does something similar. >> >> R has its own markup "Rd" and >> R CMD Rdconv >> converts Rd to plain text, LaTeX, HTML, >> or extracts examples so R can run them. >> R CMD Rd2pdf >> converts Rd (listed files, or in a directory) >> to PDF. >> R CMD Rd2txt >> converts Rd to plain text >> This means that it's possible to write a 'man' equivalent >> for R if you know where the Rd files are. It also supports >> >> help(topic, package = NULL, lib.loc = NULL, >> verbose = getOption("verbose"), >> try.all.packages = getOption("help.try.all.packages"), >> help_type = getOption("help_type")) >> help.search(pattern, fields = c("alias", "concept", "title"), >> apropos, keyword, whatis, ignore.case = TRUE, >> package = NULL, lib.loc = NULL, >> help.db = getOption("help.db"), >> verbose = getOption("verbose"), >> rebuild = FALSE, agrep = NULL, use_UTF8 = FALSE, >> types = getOption("help.search.types")) >> ??pattern >> field??pattern >> ?word >> >> in the REPL, and of course help() and help.search() >> may be called from code. >> >> Note that a good way to store XML is to use a compressor like XMill. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lutz Behnke > Hochschule f?r Angewandte Wissenschaften Hamburg, > Labor f?r Allgemeine Informatik, > > phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED > fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage > Berliner Tor 7, 20099 Hamburg, Germany > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From essen@REDACTED Thu Sep 29 13:14:13 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Thu, 29 Sep 2016 13:14:13 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: References: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> Message-ID: <5de56e7f-1ffe-3113-ac6c-6ba850a32f0b@ninenines.eu> On 09/29/2016 12:22 PM, Joe Armstrong wrote: > On Thu, Sep 29, 2016 at 9:43 AM, Lutz Behnke > wrote: >> Hi all, >> >> the discussion leaves me with the impression that everybody has his or her >> own method of accessing the documentation. And even that may change >> according to circumstances. I think a solution should be modular to cater to >> a wide range of personal preferences and situational restrictions. >> >> Joe's suggestion of a REST engine, that can provide the documentation in the >> format of your choice, does not automatically mean it only works online. > > Not really - whatever you do on-line can easily be achieved with > a local webserver which can be packaged with the rest of the system > >> Lets write a small doc-engine that can do all that. It should run as a self >> contained program on your local machine. > > Yes - but it could use the same REST interface as above What kind of madness is this? *You should not have to run a server to read documentation!* Why would you open a socket to a local server (what port number btw?) to read a file that's *already on your filesystem*? Just open the file! I'd understand if you'd use Vlad's suggestion of adding support for an existing doc server for integration into IDEs; but a custom server on top of a custom documentation format makes absolutely no sense. You are not going to solve documentation problems by writing more programs. You solve documentation problems by writing more or improving what's already there; and in the case of OTP by reducing the amount of custom code needed to maintain it. Documentation is hard enough. Keep it *simple*. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From lutz.behnke@REDACTED Thu Sep 29 14:00:58 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Thu, 29 Sep 2016 14:00:58 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: <5de56e7f-1ffe-3113-ac6c-6ba850a32f0b@ninenines.eu> References: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> <5de56e7f-1ffe-3113-ac6c-6ba850a32f0b@ninenines.eu> Message-ID: <164c9b0a-1a35-dbf7-2ceb-5b5b8aa1976d@informatik.haw-hamburg.de> Am 29.09.2016 um 13:14 schrieb Lo?c Hoguin: > On 09/29/2016 12:22 PM, Joe Armstrong wrote: >> On Thu, Sep 29, 2016 at 9:43 AM, Lutz Behnke >> wrote: >>> Hi all, >>> >>> the discussion leaves me with the impression that everybody has his >>> or her >>> own method of accessing the documentation. And even that may change >>> according to circumstances. I think a solution should be modular to >>> cater to >>> a wide range of personal preferences and situational restrictions. >>> >>> Joe's suggestion of a REST engine, that can provide the documentation >>> in the >>> format of your choice, does not automatically mean it only works online. >> >> Not really - whatever you do on-line can easily be achieved with >> a local webserver which can be packaged with the rest of the system >> >>> Lets write a small doc-engine that can do all that. It should run as >>> a self >>> contained program on your local machine. >> >> Yes - but it could use the same REST interface as above > > What kind of madness is this? Different people consume documentation differently. > > *You should not have to run a server to read documentation!* > > Why would you open a socket to a local server (what port number btw?) to > read a file that's *already on your filesystem*? Just open the file! Because having each file for each format on disk is a waste. If you only ever want to use a single format, just prepare them for you. But don't force me to use a format, just because you like it. I don't where you see the difference between a server/filter that can do it on the fly and some thin front-end that will prepare a complete doc bundle in a desired format > > I'd understand if you'd use Vlad's suggestion of adding support for an > existing doc server for integration into IDEs; but a custom server on > top of a custom documentation format makes absolutely no sense. > > You are not going to solve documentation problems by writing more > programs. You solve documentation problems by writing more or improving > what's already there; and in the case of OTP by reducing the amount of > custom code needed to maintain it. > > Documentation is hard enough. Keep it *simple*. > Yes, but there are different people can solve different issues, due to different skill sets. Reading/groking documentation is hard too, so it makes no sense to take people out of their comfort zone when using it. For me that zone is a combination of firefox, ctrl-f and google. You like man, IIRC Joe likes PDFs, Vlad wants integration into his IDE. Each to his own. mfg lutz -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5006 bytes Desc: S/MIME Cryptographic Signature URL: From raimo+erlang-questions@REDACTED Thu Sep 29 15:30:38 2016 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 29 Sep 2016 15:30:38 +0200 Subject: [erlang-questions] gen_statem and multiple timeout vs 1 In-Reply-To: <20160926145625.GA42780@erix.ericsson.se> References: <917841123.4519860.1474824739386.ref@mail.yahoo.com> <917841123.4519860.1474824739386@mail.yahoo.com> <20160926145625.GA42780@erix.ericsson.se> Message-ID: <20160929133038.GA34091@erix.ericsson.se> After giving this a second thought i wonder if a single state timer would be a desired feature and enough in your case. Today we have an event timeout, which is seldom useful since often you are in one state and wait for something specific while stray events that either are ignored or immediately replied to passes by. The event timeout is reset for every stray event. What I think would cover many use cases is a single state timeout. It would be cancelled if you change states. If you set it again the running timer is cancelled and a new is started. There would only need to be one such timer so it is roughly as easy to implement as the event timeout. There would be no way to cancel it other than changing states. It would be started with an action {state_timeout,T,Msg}. We should keep the old {timeout,T,Msg} since it is inherited from gen_fsm and has some use cases. What do you think? / Raimo On Mon, Sep 26, 2016 at 04:56:25PM +0200, Raimo Niskanen wrote: > On Sun, Sep 25, 2016 at 05:32:19PM +0000, Vans S wrote: > > Learning the new gen_statem made me desire for one extra feature. > > > > Say you have a common use case of a webserver /w websockets, you have a general connection timeout of 120s, if no messages are received in 120s it means the socket is in an unknown state, and should be closed. > > > > So you write your returns like this anytime the client sends you a message: > > > > {next_state, NextState, NewData, {timeout, 120*1000, idle_timeout}} > > > > Now if the client does not send any messages in 120 seconds, we will get a?idle_timeout?message sent to the gen_statem process. > > > > Awesome. > > > > But enter a little complexity, enter websockets. > > > > Now we need to send a ping from the gen_statem every 15s to the client, but we also need to consider if we did not get any messages from the client in 120s, we are in unknown state and should terminate the connection. > > > > So now we are just itching to do this on init: > > > > {ok, initial_state, Data, [? ? ? ? {timeout, 120*1000,?idle_timeout},? ? ? ? {timeout, 15*1000, websocket_ping} > > ????]} > > > > This way we do not need to manage our own timers using erlang:send_after. ?timer module is not even a consideration due to how inefficient it is at scaling. > > > > But of course we cannot do this, the latest timeout will always override any previous. > > > > What do you think? > > Your use case is in the middle ground between the existing event timeout > and using erlang:start_timer/4,3, and is a special case of using > erlang:start_timer/4,3. > > The existing {timeout,T,Msg} is an *event* timeout, so you get either an > event or the timeout. The timer is cancelled by the first event. > This semantics is easy to reason about and has got a fairly simple > implementation in the state machine engine partly since it only needs > to store one timer ref. > > It seems you could use a state timeout, i.e the timeout is cancelled when > the state changes. This would require the state machine engine to hold any > number of timer refs and cancel all during a state change. > > This semantics is subtly similar to the current event timeout. It would > need a new option, e.g {state_timeout,T,Msg}. > > The {state_timeout,_,_} semantics would be just a special case of using > erlang:start_timer/4,3, keep your timer ref in the server state and cancel > it when needed, since in the general case you might want to cancel the > timer at some other state change or maybe not a state change but an event. > > So the question is if a {state_timeout,_,_} feature that auto cancels the > timer at the first state change is so useful that it is worthy of being > implemented? It is not _that_ much code that is needed to store > a timer ref and cancel the timer started with erlang:start_timer/4,3, > and it is more flexible. > > I implemented the {timeout,_,_} feature just so make it easy to port from > gen_fsm. Otherwise I thought that using explicit timers was easy enough. > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From Ingela.Anderton.Andin@REDACTED Thu Sep 29 15:30:23 2016 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 29 Sep 2016 15:30:23 +0200 Subject: [erlang-questions] Patch package OTP 19.1.1 released Message-ID: Patch Package: OTP 19.1.1 Git Tag: OTP-19.1.1 Date: 2016-09-29 Trouble Report Id: OTP-13917, OTP-13918 Seq num: System: OTP Release: 19 Application: ssl-8.0.3 Predecessor: OTP 19.1 Check out the git tag OTP-19.1.1, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- ssl-8.0.3 ------------------------------------------------------- --------------------------------------------------------------------- Note! The ssl-8.0.3 application can *not* be applied independently of other applications on an arbitrary OTP 19 installation. On a full OTP 19 installation, also the following runtime dependency has to be satisfied: -- stdlib-3.1 (first satisfied in OTP 19.1) --- Fixed Bugs and Malfunctions --- OTP-13917 Application(s): ssl A timing related bug in event handling could cause interoperability problems between an erlang TLS server and some TLS clients, especially noticed with Firefox as TLS client. OTP-13918 Application(s): ssl Correct ECC curve selection, the error could cause the default to always be selected. Full runtime dependencies of ssl-8.0.3: crypto-3.3, erts-7.0, inets-5.10.7, kernel-3.0, public_key-1.2, stdlib-3.1 --------------------------------------------------------------------- --------------------------------------------------------------------- From essen@REDACTED Thu Sep 29 15:49:57 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Thu, 29 Sep 2016 15:49:57 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: <164c9b0a-1a35-dbf7-2ceb-5b5b8aa1976d@informatik.haw-hamburg.de> References: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> <5de56e7f-1ffe-3113-ac6c-6ba850a32f0b@ninenines.eu> <164c9b0a-1a35-dbf7-2ceb-5b5b8aa1976d@informatik.haw-hamburg.de> Message-ID: On 09/29/2016 02:00 PM, Lutz Behnke wrote: >> *You should not have to run a server to read documentation!* >> >> Why would you open a socket to a local server (what port number btw?) to >> read a file that's *already on your filesystem*? Just open the file! > > Because having each file for each format on disk is a waste. If you only > ever want to use a single format, just prepare them for you. But don't > force me to use a format, just because you like it. But that's already the case. I only have man pages; I don't have HTML or PDF. > I don't where you see the difference between a server/filter that can do > it on the fly and some thin front-end that will prepare a complete doc > bundle in a desired format You are kidding? Now Erlang needs to come with converters for every format people use. I'm advocating using a third party tool that handles all this mess automatically and produce the files along the release; up to you whether to install them or not. My development system only has man pages; my CI servers don't have any documentation, as it should be. >> I'd understand if you'd use Vlad's suggestion of adding support for an >> existing doc server for integration into IDEs; but a custom server on >> top of a custom documentation format makes absolutely no sense. >> >> You are not going to solve documentation problems by writing more >> programs. You solve documentation problems by writing more or improving >> what's already there; and in the case of OTP by reducing the amount of >> custom code needed to maintain it. >> >> Documentation is hard enough. Keep it *simple*. >> > Yes, but there are different people can solve different issues, due to > different skill sets. > > Reading/groking documentation is hard too, so it makes no sense to take > people out of their comfort zone when using it. For me that zone is a > combination of firefox, ctrl-f and google. You like man, IIRC Joe likes > PDFs, Vlad wants integration into his IDE. Each to his own. Didn't say it couldn't be useful to integrate into IDEs. It's the rest that I have problems with. We don't need more custom code for building the documentation; we need less. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From t6sn7gt@REDACTED Thu Sep 29 16:22:30 2016 From: t6sn7gt@REDACTED (Donald Steven) Date: Thu, 29 Sep 2016 10:22:30 -0400 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused Message-ID: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> Hi everyone, Can someone please put me out of my (extended) misery? The part of the code that's causing the problem is: ============================= loop(Orbiter1) -> receive {Orbiter1, Coordinates} -> X = element(1, element(1, Coordinates)), Y = element(2, element(1, Coordinates)), Z = element(3, element(1, Coordinates)) end, io:format("Coordinates: ~p~n", [Coordinates]), io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]) loop(Orbiter1). ============================= which produces the error: base.erl:48: variable 'Coordinates' unsafe in 'receive' (line 35) base.erl:37: Warning: variable 'X' is unused base.erl:37: Warning: variable 'Y' is unused base.erl:38: Warning: variable 'Z' is unused {"init terminating in do_boot",{undef,[{base,main,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}} init terminating in do_boot () ============================= Thanks for your help. Don From vladdu55@REDACTED Thu Sep 29 16:34:32 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 29 Sep 2016 16:34:32 +0200 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> Message-ID: Hi! What you probably want to do is loop(Orbiter1) -> Coordinates = receive {Orbiter1, Coordinates} -> Coordinates end, {X, Y, Z} = Coordinates, io:format("Coordinates: ~p~n", [Coordinates]), io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]) loop(Orbiter1). regards, Vlad On Thu, Sep 29, 2016 at 4:22 PM, Donald Steven wrote: > Hi everyone, > > Can someone please put me out of my (extended) misery? The part of the > code that's causing the problem is: > > ============================= > > loop(Orbiter1) -> > > receive > > {Orbiter1, Coordinates} -> X = element(1, element(1, > Coordinates)), Y = element(2, element(1, Coordinates)), > Z = element(3, element(1, Coordinates)) > end, > > io:format("Coordinates: ~p~n", [Coordinates]), > io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]) > > loop(Orbiter1). > > ============================= > > which produces the error: > > base.erl:48: variable 'Coordinates' unsafe in 'receive' (line 35) > base.erl:37: Warning: variable 'X' is unused > base.erl:37: Warning: variable 'Y' is unused > base.erl:38: Warning: variable 'Z' is unused > > {"init terminating in do_boot",{undef,[{base,main,[] > ,[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}} > init terminating in do_boot () > > ============================= > > Thanks for your help. > > Don > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Thu Sep 29 16:52:06 2016 From: t6sn7gt@REDACTED (Donald Steven) Date: Thu, 29 Sep 2016 10:52:06 -0400 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> Message-ID: <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Thu Sep 29 17:02:58 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 29 Sep 2016 17:02:58 +0200 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> Message-ID: The crash is because the message doesn't look like I assumed. I didn't pay attention and didn't see that it should be {{X, Y, Z}} = Coordinates (two levels of braces) To get rid of the warning, you can rewrite loop(Orbiter1) -> receive {Orbiter1, Coordinates={{X,Y,Z}}} -> io:format("Coordinates: ~p~n", [Coordinates]), io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]) end, loop(Orbiter1). For a real server, you probably want to handle more messages, and ignore those you don't care about. For example loop(Orbiter1) -> receive {Orbiter1, Coordinates={{X,Y,Z}}} -> io:format("Coordinates: ~p~n", [Coordinates]), io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]), loop(Orbiter1); _ -> ok % stop if unknown message arrives end. regards, Vlad On Thu, Sep 29, 2016 at 4:52 PM, Donald Steven wrote: > Alas that produces: > > problem.erl:26: Warning: variable 'Coordinates' exported from 'receive' > (line 26) > {"init terminating in do_boot",{{badmatch,{{-4.99800 > 0e+02,6.000000e-01,2.000000e-01}}},[{problem,loop,1,[{file, > "problem.erl"},{line,29}]},{init,start_em,1,[]},{init,do_boot,3,[]}]}} > init terminating in do_boot () > > On 09/29/2016 10:34 AM, Vlad Dumitrescu wrote: > > loop(Orbiter1) -> > Coordinates = receive > {Orbiter1, Coordinates} -> Coordinates > end, > {X, Y, Z} = Coordinates, > io:format("Coordinates: ~p~n", [Coordinates]), > io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]) > loop(Orbiter1). > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trenthampton@REDACTED Thu Sep 29 17:52:25 2016 From: trenthampton@REDACTED (Trent Hampton) Date: Thu, 29 Sep 2016 09:52:25 -0600 Subject: [erlang-questions] Monitor Sockets Message-ID: <6151164A-5967-4C4E-BFB4-57EA66821050@gmail.com> In January 2013, Loic suggested a feature to monitor sockets. The suggestion can be found here: http://erlang.org/pipermail/erlang-questions/2013-January/071668.html Was socket monitoring implemented? If not, then is there a way to monitor, on a server, when a client closes a socket? I am using ranch. Thank you, Trent Hampton From t6sn7gt@REDACTED Thu Sep 29 18:29:14 2016 From: t6sn7gt@REDACTED (Donald Steven) Date: Thu, 29 Sep 2016 12:29:14 -0400 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> Message-ID: <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Thu Sep 29 19:21:44 2016 From: t6sn7gt@REDACTED (Donald Steven) Date: Thu, 29 Sep 2016 13:21:44 -0400 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused [SOLVED] In-Reply-To: References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> Message-ID: <6d3a04c8-17f4-42d4-ce5c-5415b2965524@aim.com> An HTML attachment was scrubbed... URL: From vans_163@REDACTED Thu Sep 29 18:47:08 2016 From: vans_163@REDACTED (Vans S) Date: Thu, 29 Sep 2016 16:47:08 +0000 (UTC) Subject: [erlang-questions] Monitor Sockets In-Reply-To: <6151164A-5967-4C4E-BFB4-57EA66821050@gmail.com> References: <6151164A-5967-4C4E-BFB4-57EA66821050@gmail.com> Message-ID: <1893051380.6864338.1475167628456@mail.yahoo.com> I am interested in this too. ?I noticed under load Erlang does not properly close sockets and produces a read error on the peer. ?I documented the behavior in this issue?apr_socket_connect(): Connection reset by peer (104) ? Issue #1 ? vans163/stargate On Thursday, September 29, 2016 12:00 PM, Trent Hampton wrote: In January 2013, Loic suggested a feature to monitor sockets. The suggestion can be found here: http://erlang.org/pipermail/erlang-questions/2013-January/071668.html Was socket monitoring implemented? If not, then is there a way to monitor, on a server, when a client closes a socket? I am using ranch. Thank you, Trent Hampton _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Thu Sep 29 20:53:31 2016 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 29 Sep 2016 20:53:31 +0200 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> Message-ID: Hi Donald, I see. If you need to do processing that involves all three sets of coordinates, you can't do it like that because after each receive you can only know one set, the one just received. You have to keep the coords in the server state. This is a simple alternative (sorry for the short names). % State is [{Orbiter1, {X1, Y1, Z1}}, ...] orbiter(State) -> receive {O, C} -> State1 = updateState(State, {O, C}), process_state(State1), orbiter(State1); _ -> % something ok end. This is quite standard simple server, I suggest you check a good introduction to that. http://learnyousomeerlang.com/ is my favorite. regards, Vlad On Thu, Sep 29, 2016 at 6:29 PM, Donald Steven wrote: > Thanks Vlad, that works. However, there are really 3 orbiters and I need > to use the values of X1, Y1, Z1, X2, Y2, Z2, and X3, Y3 and Z3 outside of > the 'receive', to compare them, calculate distances between points, etc. > > When I try: > > loop(Orbiter1, Orbiter2, Orbiter3) -> > > receive > {Orbiter1, Coordinates = {{X1, Y1, Z1}}} -> % the > io:format statements are just fro debugging. What I really need > io:format("Coordinates: ~p~n", [Coordinates]), % > are the X1, Y1, and Z1 coordinates so that I can do some work with them > io:format("X1: ~p, Y1: ~p, Z1: ~p~n", [X1, Y1, Z1]); % > beyond the end of the 'receive' > {Orbiter2, Coordinates = {{X2, Y2, Z2}}} -> > io:format("Coordinates: ~p~n", [Coordinates]), > io:format("X2: ~p, Y2: ~p, Z2: ~p~n", [X2, Y2, Z2]); > {Orbiter3, Coordinates = {{X3, Y3, Z3}}} -> > io:format("Coordinates: ~p~n", [Coordinates]), > io:format("X3: ~p, Y3: ~p, Z3: ~p~n", [X3, Y3, Z3]); > _ -> > ok % stop if unknown message arrives > end, > > io:format("X1: ~p, Y1: ~p, Z1: ~p~n", [X1, Y1, Z1]), % this > would really be more substantial code. This is a placeholder > loop(Orbiter1, Orbiter2, Orbiter3). > > ================= > > I get: > > problem.erl:48: variable 'X1' unsafe in 'receive' (line 34) > problem.erl:48: variable 'Y1' unsafe in 'receive' (line 34) > problem.erl:48: variable 'Z1' unsafe in 'receive' (line 34) > {"init terminating in do_boot",{undef,[{problem, > main,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}} > init terminating in do_boot () > > ================= > > but if I move the 'loop(Orbiter1, Orbiter2, Orbiter3)' statement back > within the clauses in 'receive', it never reaches the code beyond 'end,'. > > &^(**(^(*(&\&%$^&%$%^$!!!! > > In everyday English, I want to: > > 1. Get the X, Y and Z coordinates from each Orbiter (the concurrent > processes that are producing them (verified correctly)) > 2. Do some work with the coordinates (e.g., calculating how far apart the > orbiters are) > > Don > > On 09/29/2016 11:02 AM, Vlad Dumitrescu wrote: > > loop(Orbiter1) -> > receive > {Orbiter1, Coordinates={{X,Y,Z}}} -> > io:format("Coordinates: ~p~n", [Coordinates]), > io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]), > loop(Orbiter1); > _ -> > ok % stop if unknown message arrives > end. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Thu Sep 29 21:04:04 2016 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 29 Sep 2016 21:04:04 +0200 Subject: [erlang-questions] Monitor Sockets In-Reply-To: <6151164A-5967-4C4E-BFB4-57EA66821050@gmail.com> References: <6151164A-5967-4C4E-BFB4-57EA66821050@gmail.com> Message-ID: On 09/29/2016 05:52 PM, Trent Hampton wrote: > In January 2013, Loic suggested a feature to monitor sockets. The suggestion can be found here: > > http://erlang.org/pipermail/erlang-questions/2013-January/071668.html > > Was socket monitoring implemented? > > Yes, port monitoring exist in OTP 19: "OTP-11384 Application(s): erts Make it possible to monitor/demonitor ports using the erlang:monitor/2 API. The process and port information functions have also been updated to include information about monitors from processes to ports." /Sverker From t6sn7gt@REDACTED Thu Sep 29 21:32:31 2016 From: t6sn7gt@REDACTED (Donald Steven) Date: Thu, 29 Sep 2016 15:32:31 -0400 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> Message-ID: <13da8bf0-c794-d5a0-9a30-7b9e5e9f72c6@aim.com> An HTML attachment was scrubbed... URL: From kennethlakin@REDACTED Fri Sep 30 01:11:46 2016 From: kennethlakin@REDACTED (Kenneth Lakin) Date: Thu, 29 Sep 2016 16:11:46 -0700 Subject: [erlang-questions] Patch package OTP 19.1.1 released In-Reply-To: References: Message-ID: On 09/29/2016 06:30 AM, Ingela Anderton Andin wrote: > OTP-13917 Application(s): ssl > > A timing related bug in event handling could cause > interoperability problems between an erlang TLS server > and some TLS clients, especially noticed with Firefox > as TLS client. Awesome. Now TLS client certificate processing works when the client is a Microsoft client (whether it's Edge, Internet Explorer, or the Windows EAP-TLS family of clients), and doesn't die with a "Handshake error" alert! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rexxe98@REDACTED Fri Sep 30 01:12:56 2016 From: rexxe98@REDACTED (Andrew Berman) Date: Thu, 29 Sep 2016 23:12:56 +0000 Subject: [erlang-questions] HTTP/2 client Message-ID: Is there a production ready HTTP/2 client available in Erlang? I've searched and only found Gun to have some support for HTTP/2, but when I tried to use it I got an error, and it looks like it's not quite ready for primetime (correct me if I'm wrong, Lo?c). Thanks! Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From denc716@REDACTED Fri Sep 30 02:03:20 2016 From: denc716@REDACTED (derek) Date: Thu, 29 Sep 2016 17:03:20 -0700 Subject: [erlang-questions] HTTP/2 client In-Reply-To: References: Message-ID: On Thu, Sep 29, 2016 at 4:12 PM, Andrew Berman wrote: > Is there a production ready HTTP/2 client available in Erlang? I've > searched and only found Gun to have some support for HTTP/2, but when I > tried to use it I got an error, and it looks like it's not quite ready for > primetime (correct me if I'm wrong, Lo?c). the page mentioned Chatterbox, have you tested that? https://github.com/http2/http2-spec/wiki/Implementations Chatterbox Erlang Server, Client ALPN h2 https://github.com/joedevivo/chatterbox From ok@REDACTED Fri Sep 30 02:04:20 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 30 Sep 2016 13:04:20 +1300 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <147ccb11-7629-36c2-1a44-212050301399@cs.otago.ac.nz> Message-ID: <2284dcac-9ff4-6931-8415-f6849b6dc539@cs.otago.ac.nz> On 29/09/16 8:11 PM, Vlad Dumitrescu wrote: > Regarding how Joe is using the docs. How can one provide a static HTML > that is able to guess > which mode the user is in right now ('beginner' or 'expert')? I guess I didn't express myself clearly. THERE IS NO SUCH MODE. At ALL times, people are more or less expert about some things and more or less ignorant about other things. Even beginners need precise reference material. Even experts are ignorant of much that is in the precise reference material. ALL readers are PART expert PART beginner ALL THE TIME. (Heck, just a couple of days ago I found something in the C math library I hadn't known about, and I not only have copies of all the C standards, I have source for several C math libraries which I trawl through from time to time.) If you want dynamic, then one way is to do what I have suggested about examples and Joe just suggested about other stuff: - you have a very brief "reminder" / "cheat sheet" entry per topic - you have "reveal details" / "reveal examples" &c buttons underneath At this point I must retract what I said about JavaScript, which was too harsh. Hooking the buttons to CSS properties to support hide/reveal is a great use of JavaScript; one of the neat things about it is that ALL the material is there in the page ready for indexing. From mkbucc@REDACTED Fri Sep 30 03:25:07 2016 From: mkbucc@REDACTED (Mark Bucciarelli) Date: Thu, 29 Sep 2016 21:25:07 -0400 Subject: [erlang-questions] concurrency question Message-ID: I have a program that does the following: - start gen_event, naming it "dispatcher" - spawn a process - send 60 message to process then a stop message - exit The spawned process outputs a line to stdout for each message recieved, and after 40 or so messages, the spawned process calls gen_event:notify(dispatcher, ...). This has the obvious bug that when the event is fired, the dispatcher is long gone. When I run this from the command line like this: erl -run simulation -run init stop the spawned process does not print any error message to the console when it crashes. But when I run it from inside the interpreter, > simulation:start(). I see: ** exception error: no such process or port (which is gen_event saying hey, I can't notify the Pid with that name because it's gone.) Why don't I get that error output when I run from the console? Thanks! Mark -- Blogging at markbucciarelli.com Tweeting @mbucc -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Sep 30 03:54:06 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 30 Sep 2016 14:54:06 +1300 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> Message-ID: <867982fa-5813-9a51-c198-6e9621c0d94c@cs.otago.ac.nz> On 30/09/16 3:22 AM, Donald Steven wrote: [The basic problem is that % Tag is defined here, Datum and Value are not receive {Tag,Datum} -> Value = f(Datum) end, use(Datum, Value) produces warnings about unsafe variables.] If a variable is defined in some branch(es) of a case or receive but not others, it is in scope after the case or receive, but as it might not be defined, it is unsafe. In this case, it looks to me as if the compiler is wrong. There is no path through the receive that doesn't define all the variables. You could write loop(Orbiter1) -> Coordinates = receive {Orbiter1, C} -> C end, V = element(1, Coordinates), X = element(1, V), Y = element(2, V), Z = element(3, V), io:format("Coordinates: ~p~n", [Coordinates]), io:format("X: ~p, Y: ~p, Z: ~p~n", [X, Y, Z]), loop(Orbiter1). which the compiler is happy with. From mkbucc@REDACTED Fri Sep 30 04:03:31 2016 From: mkbucc@REDACTED (Mark Bucciarelli) Date: Thu, 29 Sep 2016 22:03:31 -0400 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: On Thu, Sep 29, 2016 at 2:07 AM, Joe Armstrong wrote: > - change the ordering (it's alphabetic) - I'd like a 'best of' (or > essential functions first) - the minimal set you should know about > I was thinking about this today. Would it be useful to download Erlang projects from github and compute frequency of use of each Erlang function across all downloaded projects? That would be one way to make a first pass of all modules ... The UI could perhaps make two buckets per module: "frequently used" and "other", and collapse the latter set to minimize the visual space used. It would take a while ... $ curl -s https://api.github.com/search/repositories?q=language:erlang \ > | grep total_count "total_count": 17538, ... maybe take a random sample or filter out dormant and really big projects. Mark -- Blogging at markbucciarelli.com Tweeting @mbucc -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Sep 30 04:24:31 2016 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 30 Sep 2016 15:24:31 +1300 Subject: [erlang-questions] Newbie help please with variable unsafe in 'receive' & variable unused In-Reply-To: <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> Message-ID: <62f51810-73e3-6a5b-5037-3fdfb3a3e9bd@cs.otago.ac.nz> On 30/09/16 5:29 AM, Donald Steven wrote: > > loop(Orbiter1, Orbiter2, Orbiter3) -> > > receive > {Orbiter1, Coordinates = {{X1, Y1, Z1}}} -> % > the io:format statements are just fro debugging. What I really need > io:format("Coordinates: ~p~n", [Coordinates]), % > are the X1, Y1, and Z1 coordinates so that I can do some work with them > io:format("X1: ~p, Y1: ~p, Z1: ~p~n", [X1, Y1, Z1]); % > beyond the end of the 'receive' > {Orbiter2, Coordinates = {{X2, Y2, Z2}}} -> > io:format("Coordinates: ~p~n", [Coordinates]), > io:format("X2: ~p, Y2: ~p, Z2: ~p~n", [X2, Y2, Z2]); > {Orbiter3, Coordinates = {{X3, Y3, Z3}}} -> > io:format("Coordinates: ~p~n", [Coordinates]), > io:format("X3: ~p, Y3: ~p, Z3: ~p~n", [X3, Y3, Z3]); > _ -> > ok % stop if unknown message arrives > end, > > io:format("X1: ~p, Y1: ~p, Z1: ~p~n", [X1, Y1, Z1]), % this > would really be more substantial code. This is a placeholder > loop(Orbiter1, Orbiter2, Orbiter3). At your "placeholder" line, if an {Orbiter2, {{X2,Y2,Z2}}} message arrived, what values do you expect X1,Y1,Z1 to have, and why do you expect them to have those values? I would suggest code like loop(Orbiter1, Orbiter2, Orbiter3) -> receive {Orbiter1, {XYZ}} -> handle(1, Orbiter1, XYZ) ; {Orbiter2, {XYZ}} -> handle(2, Orbiter2, XYZ) ; {Orbiter3, {XYZ}} -> handle(3, Orbiter3, XYZ) ; _Other -> ignored end, loop(Orbiter1, Orbiter2, Orbiter3). handle(Orbiter_Index, Orbiter, XYZ) -> % debugging io:format("Orbiter ~d coordinates = ~p~n", [Orbiter_Index, XYZ}, % real work ok. From rexxe98@REDACTED Fri Sep 30 04:27:52 2016 From: rexxe98@REDACTED (Andrew Berman) Date: Fri, 30 Sep 2016 02:27:52 +0000 Subject: [erlang-questions] HTTP/2 client In-Reply-To: References: Message-ID: Oh nice, I thought it was only a server and didn't see that it had a client. I'll check it out. Thanks! On Thu, Sep 29, 2016 at 5:03 PM derek wrote: > On Thu, Sep 29, 2016 at 4:12 PM, Andrew Berman wrote: > > Is there a production ready HTTP/2 client available in Erlang? I've > > searched and only found Gun to have some support for HTTP/2, but when I > > tried to use it I got an error, and it looks like it's not quite ready > for > > primetime (correct me if I'm wrong, Lo?c). > > the page mentioned Chatterbox, have you tested that? > > https://github.com/http2/http2-spec/wiki/Implementations > > > Chatterbox Erlang Server, Client ALPN h2 > https://github.com/joedevivo/chatterbox > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.polvorin@REDACTED Fri Sep 30 04:45:31 2016 From: pablo.polvorin@REDACTED (Pablo Polvorin) Date: Thu, 29 Sep 2016 23:45:31 -0300 Subject: [erlang-questions] HTTP/2 client In-Reply-To: References: Message-ID: Hi Andrew, maybe the problem was with dependencies?. We are evaluating gun as well, and got an error on the first try but the problem was that the version of cowlib we were using didn't include the latests http2 changes. Switching to cowlib master solved that. We aren't using it on production yet, and there are parts missing -like flow control- , but if our experience counts, so far it seems to be good enough for our use case (we need to interact with only one http/2 server implementation, on a fairly controlled way). On 29 September 2016 at 20:12, Andrew Berman wrote: > Is there a production ready HTTP/2 client available in Erlang? I've > searched and only found Gun to have some support for HTTP/2, but when I > tried to use it I got an error, and it looks like it's not quite ready for > primetime (correct me if I'm wrong, Lo?c). > > Thanks! > > Andrew > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Pablo Polvorin ProcessOne From pierrefenoll@REDACTED Fri Sep 30 09:18:30 2016 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Fri, 30 Sep 2016 09:18:30 +0200 Subject: [erlang-questions] Erlang documentation -- a modest proposal In-Reply-To: References: <1474312965.50459872@apps.rackspace.com> <4f69071d-bcec-eda2-6322-428b0ed8ee85@ninenines.eu> <52803f0c-e906-51b3-fe13-63291ef68902@gmail.com> <66361144-3156-2cd8-693f-984676f2bebd@cs.otago.ac.nz> <3a97bd90-b149-b517-8f7f-a73d58174ed0@ninenines.eu> Message-ID: <311CA5D4-A9B2-4526-897F-2AAEC04D7F9F@gmail.com> I can run such a task on the daily construction of dev.erldocs.com. Could you specify what branches / tags should be looked at per project, as it seems that would skew results? Dev.erldocs.com is the beta of other.erldocs.com where people will be able to issue PRs to create jobs such as yours ;) > On 30 Sep 2016, at 04:03, Mark Bucciarelli wrote: > >> On Thu, Sep 29, 2016 at 2:07 AM, Joe Armstrong wrote: >> - change the ordering (it's alphabetic) - I'd like a 'best of' (or >> essential functions first) - the minimal set you should know about > > I was thinking about this today. > > Would it be useful to download Erlang projects from github > and compute frequency of use of each Erlang function across > all downloaded projects? > > That would be one way to make a first pass of all modules ... > > The UI could perhaps make two buckets per module: "frequently > used" and "other", and collapse the latter set to minimize the > visual space used. > > It would take a while ... > $ curl -s https://api.github.com/search/repositories?q=language:erlang \ > > > | grep total_count > > "total_count": 17538, > > ... maybe take a random sample or filter out dormant and really big projects. > > > Mark > > -- > Blogging at markbucciarelli.com > Tweeting @mbucc > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.behnke@REDACTED Fri Sep 30 09:30:20 2016 From: lutz.behnke@REDACTED (Lutz Behnke) Date: Fri, 30 Sep 2016 09:30:20 +0200 Subject: [erlang-questions] Accessing the documentation at runtime In-Reply-To: References: <4b359f11-d919-2615-cde6-582c126fe281@cs.otago.ac.nz> <57816788-b5b7-0f8e-60f0-651678dba851@informatik.haw-hamburg.de> <5de56e7f-1ffe-3113-ac6c-6ba850a32f0b@ninenines.eu> <164c9b0a-1a35-dbf7-2ceb-5b5b8aa1976d@informatik.haw-hamburg.de> Message-ID: <0622e82b-c984-e2d2-4e97-b4592a5926ae@informatik.haw-hamburg.de> Am 29.09.2016 um 15:49 schrieb Lo?c Hoguin: > On 09/29/2016 02:00 PM, Lutz Behnke wrote: >>> *You should not have to run a server to read documentation!* >>> >>> Why would you open a socket to a local server (what port number btw?) to >>> read a file that's *already on your filesystem*? Just open the file! >> >> Because having each file for each format on disk is a waste. If you only >> ever want to use a single format, just prepare them for you. But don't >> force me to use a format, just because you like it. > > But that's already the case. I only have man pages; I don't have HTML or > PDF. > >> I don't where you see the difference between a server/filter that can do >> it on the fly and some thin front-end that will prepare a complete doc >> bundle in a desired format > > You are kidding? No, I think I structured the sentence poorly. It should have been "a server/filter vs the filter plus a thin frontend for a-priory preparation". Where do you see the massive difference? > > Now Erlang needs to come with converters for every format people use. > I'm advocating using a third party tool that handles all this mess > automatically and produce the files along the release; up to you whether > to install them or not. I never said that the solution has to be written from scratch. Quite the contrary. Although there will have to be some adaption work to be done. > > My development system only has man pages; my CI servers don't have any > documentation, as it should be. > >>> I'd understand if you'd use Vlad's suggestion of adding support for an >>> existing doc server for integration into IDEs; but a custom server on >>> top of a custom documentation format makes absolutely no sense. >>> >>> You are not going to solve documentation problems by writing more >>> programs. You solve documentation problems by writing more or improving >>> what's already there; and in the case of OTP by reducing the amount of >>> custom code needed to maintain it. >>> >>> Documentation is hard enough. Keep it *simple*. >>> >> Yes, but there are different people can solve different issues, due to >> different skill sets. >> >> Reading/groking documentation is hard too, so it makes no sense to take >> people out of their comfort zone when using it. For me that zone is a >> combination of firefox, ctrl-f and google. You like man, IIRC Joe likes >> PDFs, Vlad wants integration into his IDE. Each to his own. > > Didn't say it couldn't be useful to integrate into IDEs. It's the rest > that I have problems with. We don't need more custom code for building > the documentation; we need less. > -- Lutz Behnke Hochschule f?r Angewandte Wissenschaften Hamburg, Labor f?r Allgemeine Informatik, phone: +49 40 42875-8156 mailto:lutz.behnke@REDACTED fax : +49 40 2803770 http://users.informatik.haw-hamburg.de/~sage Berliner Tor 7, 20099 Hamburg, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5006 bytes Desc: S/MIME Cryptographic Signature URL: From rexxe98@REDACTED Fri Sep 30 09:46:56 2016 From: rexxe98@REDACTED (Andrew Berman) Date: Fri, 30 Sep 2016 07:46:56 +0000 Subject: [erlang-questions] HTTP/2 client In-Reply-To: References: Message-ID: Hi Pablo, Possibly that was the issue, I'll try again, but I do see a bunch of TODOs in the gun code for HTTP/2, so it doesn't seem as ready for production use as the Chatterbox client Derek mentioned. Thanks, Andrew On Thu, Sep 29, 2016 at 7:45 PM Pablo Polvorin < pablo.polvorin@REDACTED> wrote: > Hi Andrew, maybe the problem was with dependencies?. We are > evaluating gun as well, and got an error on the first try but the > problem was that the version of cowlib we were using didn't include > the latests http2 changes. Switching to cowlib master solved that. > We aren't using it on production yet, and there are parts missing > -like flow control- , but if our experience counts, so far it seems > to be good enough for our use case (we need to interact with only one > http/2 server implementation, on a fairly controlled way). > > > > > On 29 September 2016 at 20:12, Andrew Berman wrote: > > Is there a production ready HTTP/2 client available in Erlang? I've > > searched and only found Gun to have some support for HTTP/2, but when I > > tried to use it I got an error, and it looks like it's not quite ready > for > > primetime (correct me if I'm wrong, Lo?c). > > > > Thanks! > > > > Andrew > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -- > Pablo Polvorin > ProcessOne > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Sep 30 10:04:00 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 30 Sep 2016 10:04:00 +0200 Subject: [erlang-questions] HTTP/2 client In-Reply-To: References: Message-ID: <845a54dd-a8a7-84f1-4f6e-ce35b58d1310@ninenines.eu> I do not know if the people using Gun in production so far have tried the HTTP/2 support we currently have. Personally all I can say is that it works fine with Cowboy 2, but then again Cowboy 2 doesn't have flow control either at this time. Gun and Cowboy 2 are developed concurrently so they'll always be compatible. Other servers, I suppose it depends on how strict they implement flow control. Not aware of an issue yet, but would love some feedback on it. On 09/30/2016 09:46 AM, Andrew Berman wrote: > Hi Pablo, > > Possibly that was the issue, I'll try again, but I do see a bunch of > TODOs in the gun code for HTTP/2, so it doesn't seem as ready for > production use as the Chatterbox client Derek mentioned. > > Thanks, > > Andrew > > On Thu, Sep 29, 2016 at 7:45 PM Pablo Polvorin > > > wrote: > > Hi Andrew, maybe the problem was with dependencies?. We are > evaluating gun as well, and got an error on the first try but the > problem was that the version of cowlib we were using didn't include > the latests http2 changes. Switching to cowlib master solved that. > We aren't using it on production yet, and there are parts missing > -like flow control- , but if our experience counts, so far it seems > to be good enough for our use case (we need to interact with only one > http/2 server implementation, on a fairly controlled way). > > > > > On 29 September 2016 at 20:12, Andrew Berman > wrote: > > Is there a production ready HTTP/2 client available in Erlang? I've > > searched and only found Gun to have some support for HTTP/2, but > when I > > tried to use it I got an error, and it looks like it's not quite > ready for > > primetime (correct me if I'm wrong, Lo?c). > > > > Thanks! > > > > Andrew > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -- > Pablo Polvorin > ProcessOne > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From t6sn7gt@REDACTED Fri Sep 30 15:25:49 2016 From: t6sn7gt@REDACTED (Donald Steven) Date: Fri, 30 Sep 2016 09:25:49 -0400 Subject: [erlang-questions] Newbie question: function include/1 undefined In-Reply-To: <13da8bf0-c794-d5a0-9a30-7b9e5e9f72c6@aim.com> References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> <13da8bf0-c794-d5a0-9a30-7b9e5e9f72c6@aim.com> Message-ID: <529a87be-d137-14be-68cb-bdcd231ad64d@aim.com> Hi all, I can get '-include(' to work before the main() function, but I can't get it to work *in* a function, either using a comma or a period at end. -------------------------- This works (before main()): -include("filename.hrl"). but neither of these work: main() -> -include("filename.hrl"). -include("filename.hrl"), -------------------------- Thanks for your help. Don From erlang.org@REDACTED Fri Sep 30 15:32:38 2016 From: erlang.org@REDACTED (Stanislaw Klekot) Date: Fri, 30 Sep 2016 15:32:38 +0200 Subject: [erlang-questions] Newbie question: function include/1 undefined In-Reply-To: <529a87be-d137-14be-68cb-bdcd231ad64d@aim.com> References: <344887da-4b80-a5c2-de48-d76a7285649f@aim.com> <3e605a3a-4929-56a7-16cf-52279a3c7da1@aim.com> <4a83baff-278c-ed0e-a7dd-a67412b66b93@aim.com> <13da8bf0-c794-d5a0-9a30-7b9e5e9f72c6@aim.com> <529a87be-d137-14be-68cb-bdcd231ad64d@aim.com> Message-ID: <20160930133238.GA21461@jarowit.net> On Fri, Sep 30, 2016 at 09:25:49AM -0400, Donald Steven wrote: > Hi all, > > I can get '-include(' to work before the main() function, but I > can't get it to work *in* a function, either using a comma or a > period at end. It doesn't work that way. This is a compiler's directive, not a statement. It's interpreted at the compilation time, not when you execute code. What do you actually want to achieve with this? -- Stanislaw Klekot From vans_163@REDACTED Fri Sep 30 16:25:13 2016 From: vans_163@REDACTED (Vans S) Date: Fri, 30 Sep 2016 14:25:13 +0000 (UTC) Subject: [erlang-questions] gen_statem and multiple timeout vs 1 In-Reply-To: <20160929133038.GA34091@erix.ericsson.se> References: <917841123.4519860.1474824739386.ref@mail.yahoo.com> <917841123.4519860.1474824739386@mail.yahoo.com> <20160926145625.GA42780@erix.ericsson.se> <20160929133038.GA34091@erix.ericsson.se> Message-ID: <287809764.7376616.1475245513197@mail.yahoo.com> The reasoning behind this is because I am using a?handle_event_function callback mode. I find this is more flexible. ?A standard state machine can be in 1 state at 1 time. But things are more complex now and the desire for a state machine to be in multiple states at 1 time is crucial. ? For example you can be running and screaming. Not only running then stopping to transition to screaming, then stop screaming and start running again. Maybe this is beyond the scope of a state machine, excuse if my terminology is off. If the implementation is quite simple using timers, I would not mind putting in the pull request. ?I just came here to discuss about it and see if it is something that fits. The rational is using erlang:send_after/3 is not enough in more complex cases, we need to also be stopping and starting new timers. ? An example of this is say if we are in a running state and every 100 ms we timeout, when we timeout we take an extra step and update our position in the world, also we determine how fast we are running and maybe the next step will be in 80ms now. Now while we are running, we also got a moral boost by seeing a well lit street, so in 5000ms our moral boost will expire, and will timeout. Also we start screaming due to panic, every 500ms we send a scream to all nearby recipients. Maybe this is all beyond the scope of a state machine. ?But for me it seems the only change required to support this is allowing multiple timers, and Erlang always had the design philosophy of "do what works" vs "do what is academically sound". On Thursday, September 29, 2016 9:30 AM, Raimo Niskanen wrote: After giving this a second thought i wonder if a single state timer would be a desired feature and enough in your case. Today we have an event timeout, which is seldom useful since often you are in one state and wait for something specific while stray events that either are ignored or immediately replied to passes by.? The event timeout is reset for every stray event. What I think would cover many use cases is a single state timeout.? It would be cancelled if you change states.? If you set it again the running timer is cancelled and a new is started.? There would only need to be one such timer so it is roughly as easy to implement as the event timeout. There would be no way to cancel it other than changing states. It would be started with an action {state_timeout,T,Msg}. We should keep the old {timeout,T,Msg} since it is inherited from gen_fsm and has some use cases. What do you think? / Raimo On Mon, Sep 26, 2016 at 04:56:25PM +0200, Raimo Niskanen wrote: > On Sun, Sep 25, 2016 at 05:32:19PM +0000, Vans S wrote: > > Learning the new gen_statem made me desire for one extra feature. > > > > Say you have a common use case of a webserver /w websockets, you have a general connection timeout of 120s, if no messages are received in 120s it means the socket is in an unknown state, and should be closed. > > > > So you write your returns like this anytime the client sends you a message: > > > > {next_state, NextState, NewData, {timeout, 120*1000, idle_timeout}} > > > > Now if the client does not send any messages in 120 seconds, we will get a?idle_timeout?message sent to the gen_statem process. > > > > Awesome. > > > > But enter a little complexity, enter websockets. > > > > Now we need to send a ping from the gen_statem every 15s to the client, but we also need to consider if we did not get any messages from the client in 120s, we are in unknown state and should terminate the connection. > > > > So now we are just itching to do this on init: > > > > {ok, initial_state, Data, [? ? ? ? {timeout, 120*1000,?idle_timeout},? ? ? ? {timeout, 15*1000, websocket_ping} > > ????]} > > > > This way we do not need to manage our own timers using erlang:send_after. ?timer module is not even a consideration due to how inefficient it is at scaling. > > > > But of course we cannot do this, the latest timeout will always override any previous. > > > > What do you think? > > Your use case is in the middle ground between the existing event timeout > and using erlang:start_timer/4,3, and is a special case of using > erlang:start_timer/4,3. > > The existing {timeout,T,Msg} is an *event* timeout, so you get either an > event or the timeout.? The timer is cancelled by the first event. > This semantics is easy to reason about and has got a fairly simple > implementation in the state machine engine partly since it only needs > to store one timer ref. > > It seems you could use a state timeout, i.e the timeout is cancelled when > the state changes.? This would require the state machine engine to hold any > number of timer refs and cancel all during a state change. > > This semantics is subtly similar to the current event timeout.? It would > need a new option, e.g {state_timeout,T,Msg}. > > The {state_timeout,_,_} semantics would be just a special case of using > erlang:start_timer/4,3, keep your timer ref in the server state and cancel > it when needed, since in the general case you might want to cancel the > timer at some other state change or maybe not a state change but an event. > > So the question is if a {state_timeout,_,_} feature that auto cancels the > timer at the first state change is so useful that it is worthy of being > implemented?? It is not _that_ much code that is needed to store > a timer ref and cancel the timer started with erlang:start_timer/4,3, > and it is more flexible. > > I implemented the {timeout,_,_} feature just so make it easy to port from > gen_fsm.? Otherwise I thought that using explicit timers was easy enough. > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From list1@REDACTED Fri Sep 30 18:18:00 2016 From: list1@REDACTED (Grzegorz Junka) Date: Fri, 30 Sep 2016 16:18:00 +0000 Subject: [erlang-questions] concurrency question In-Reply-To: References: Message-ID: On 30/09/2016 01:25, Mark Bucciarelli wrote: > I have a program that does the following: > > - start gen_event, naming it "dispatcher" > - spawn a process > - send 60 message to process then a stop message > - exit > > The spawned process outputs a line to stdout for > each message recieved, and after 40 or so messages, > the spawned process calls gen_event:notify(dispatcher, ...). > > This has the obvious bug that when the event is fired, the > dispatcher is long gone. > > When I run this from the command line like this: > > erl -run simulation -run init stop > > the spawned process does not print any error message to > the console when it crashes. > > But when I run it from inside the interpreter, > > > simulation:start(). > > I see: > > ** exception error: no such process or port > > (which is gen_event saying hey, I can't notify the Pid with that name > > because it's gone.) > > > Why don't I get that error output when I run from the console? > > If you spawn the dispatcher from the shell then it will be linked to the shell process. So, won't be actually gone. Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rexxe98@REDACTED Fri Sep 30 19:04:34 2016 From: rexxe98@REDACTED (Andrew Berman) Date: Fri, 30 Sep 2016 17:04:34 +0000 Subject: [erlang-questions] HTTP/2 client In-Reply-To: <845a54dd-a8a7-84f1-4f6e-ce35b58d1310@ninenines.eu> References: <845a54dd-a8a7-84f1-4f6e-ce35b58d1310@ninenines.eu> Message-ID: Hey Lo?c, Once I included MASTER for cowlib, things started working. Thanks, Pablo! It looks like MASTER in Gun which has the HTTP/2 code is using v1.3 of Cowlib (in the rebar.config file) which does not seem to have the HTTP/2 code. Thanks for all your hard work on these libraries! Andrew On Fri, Sep 30, 2016 at 1:04 AM Lo?c Hoguin wrote: > I do not know if the people using Gun in production so far have tried > the HTTP/2 support we currently have. Personally all I can say is that > it works fine with Cowboy 2, but then again Cowboy 2 doesn't have flow > control either at this time. > > Gun and Cowboy 2 are developed concurrently so they'll always be > compatible. Other servers, I suppose it depends on how strict they > implement flow control. Not aware of an issue yet, but would love some > feedback on it. > > On 09/30/2016 09:46 AM, Andrew Berman wrote: > > Hi Pablo, > > > > Possibly that was the issue, I'll try again, but I do see a bunch of > > TODOs in the gun code for HTTP/2, so it doesn't seem as ready for > > production use as the Chatterbox client Derek mentioned. > > > > Thanks, > > > > Andrew > > > > On Thu, Sep 29, 2016 at 7:45 PM Pablo Polvorin > > > > > wrote: > > > > Hi Andrew, maybe the problem was with dependencies?. We are > > evaluating gun as well, and got an error on the first try but the > > problem was that the version of cowlib we were using didn't include > > the latests http2 changes. Switching to cowlib master solved that. > > We aren't using it on production yet, and there are parts missing > > -like flow control- , but if our experience counts, so far it seems > > to be good enough for our use case (we need to interact with only > one > > http/2 server implementation, on a fairly controlled way). > > > > > > > > > > On 29 September 2016 at 20:12, Andrew Berman > > wrote: > > > Is there a production ready HTTP/2 client available in Erlang? > I've > > > searched and only found Gun to have some support for HTTP/2, but > > when I > > > tried to use it I got an error, and it looks like it's not quite > > ready for > > > primetime (correct me if I'm wrong, Lo?c). > > > > > > Thanks! > > > > > > Andrew > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > -- > > Pablo Polvorin > > ProcessOne > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Sep 30 19:25:30 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 30 Sep 2016 19:25:30 +0200 Subject: [erlang-questions] HTTP/2 client In-Reply-To: References: <845a54dd-a8a7-84f1-4f6e-ce35b58d1310@ninenines.eu> Message-ID: <1d5b807b-7e3c-c7cc-7832-d2f5ec88a622@ninenines.eu> My bad, the deps seem incorrect indeed. Thanks for the info! On 09/30/2016 07:04 PM, Andrew Berman wrote: > Hey Lo?c, > > Once I included MASTER for cowlib, things started working. Thanks, > Pablo! It looks like MASTER in Gun which has the HTTP/2 code is using > v1.3 of Cowlib (in the rebar.config file) which does not seem to have > the HTTP/2 code. > > Thanks for all your hard work on these libraries! > > Andrew > > On Fri, Sep 30, 2016 at 1:04 AM Lo?c Hoguin > wrote: > > I do not know if the people using Gun in production so far have tried > the HTTP/2 support we currently have. Personally all I can say is that > it works fine with Cowboy 2, but then again Cowboy 2 doesn't have flow > control either at this time. > > Gun and Cowboy 2 are developed concurrently so they'll always be > compatible. Other servers, I suppose it depends on how strict they > implement flow control. Not aware of an issue yet, but would love some > feedback on it. > > On 09/30/2016 09:46 AM, Andrew Berman wrote: > > Hi Pablo, > > > > Possibly that was the issue, I'll try again, but I do see a bunch of > > TODOs in the gun code for HTTP/2, so it doesn't seem as ready for > > production use as the Chatterbox client Derek mentioned. > > > > Thanks, > > > > Andrew > > > > On Thu, Sep 29, 2016 at 7:45 PM Pablo Polvorin > > > >> > > wrote: > > > > Hi Andrew, maybe the problem was with dependencies?. We are > > evaluating gun as well, and got an error on the first try but the > > problem was that the version of cowlib we were using didn't > include > > the latests http2 changes. Switching to cowlib master solved > that. > > We aren't using it on production yet, and there are parts missing > > -like flow control- , but if our experience counts, so far it > seems > > to be good enough for our use case (we need to interact with > only one > > http/2 server implementation, on a fairly controlled way). > > > > > > > > > > On 29 September 2016 at 20:12, Andrew Berman > > > >> wrote: > > > Is there a production ready HTTP/2 client available in > Erlang? I've > > > searched and only found Gun to have some support for HTTP/2, but > > when I > > > tried to use it I got an error, and it looks like it's not quite > > ready for > > > primetime (correct me if I'm wrong, Lo?c). > > > > > > Thanks! > > > > > > Andrew > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > -- > > Pablo Polvorin > > ProcessOne > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > http://ninenines.eu > Author of The Erlanger Playbook, > A book about software development using Erlang > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang