From zxq9@REDACTED Wed May 1 09:34:15 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Wed, 01 May 2019 16:34:15 +0900 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> Message-ID: <2488191.ISzvMvNNWm@takoyaki> On 2019?4?29???? 11?21?33? JST DOBRO wrote: > Hi, > could anyone explain me how is it possible? > > In shell: > > 1> <<24930>> =:= <<98>>. > true Your trying to put 24930 into a space that can hold a max value of 255. If you want that entire value to be represented you have to give it enough ROOM (in terms of bits) to reside there. Contemplate the following carefully: 1> <<0>>. <<0>> 2> <<0:8>>. <<0>> 3> <<0:32>>. <<0,0,0,0>> 4> <<1:32>>. <<0,0,0,1>> 5> <<255:32>>. <<0,0,0,255>> 6> <<256:32>>. <<0,0,1,0>> 7> <<24930:32>>. <<0,0,97,98>> 8> <<_:24, 98:8>> = <<24930:32>>. <<0,0,97,98>> -Craig From dieter@REDACTED Thu May 2 09:28:09 2019 From: dieter@REDACTED (dieter@REDACTED) Date: Thu, 02 May 2019 07:28:09 +0000 Subject: [erlang-questions] lexer for IEEE488.2 numbers In-Reply-To: References: <76473f3cf7761ad9416bc82d97db70fc@afterlogic.edis.at> Message-ID: Hello Mikael, thank you for the explanation! Of course the reasons for the implementation of list_to_float/1 is due to the erlang requirements. When your mileage varies, you have to walk a bit.. Right now I have implemented my conversion with some regular expressions, as I need this only for reading configuration definitions, which is not performance-critical. kind regards, dieter On 27.04.19 10:30, Mikael Pettersson wrote: On Thu, Apr 25, 2019 at 6:04 PM (mailto:dieter@REDACTED) wrote: Hi all, I am writing a lexer for a SCPI parser. The number format of 488.2 is more tolerant than list_to_float/1, it seems. .123 and 456. are both valid in 488.2, but list_to_float/1 rejects them. I have not yet found an erlang alternative to list_to_float/1, my current approach is to add the omitted zeroes and feed the patched string to list_to_float/1. This works if the number is only a mantissa, but it gets a bit more complicated when there is also an exponent, like 123.e11 my leex expression for the number looks like {MANTISSA}{EXPONENT} : {token, {float, TokenLine, i488tofloat(TokenChars)}}. With this approach, I have to parse the string in my function a second time, which is not elegant at all. Is there a way to have access to the regex macros (or regex groups) on the left side, like 1, 2? I already tried to push back zeroes, but immediately ran into the promised consequences from note 4 on http://erlang.org/doc/man/leex.html (http://erlang.org/doc/man/leex.html), so I quickly left that alley. The question might be heretic, but why is list_to_float so strict? Every calculator allows to omit a leading 0 before the decimal point. list_to_float is there to convert Erlang-style floating-point numbers, not anyone else's, and since Erlang has some restrictions(*) on its floats, that's reflected in this function. This is normal. C's strtoul() for instance can't convert Erlang-style Base#Digits numbers. You have two options: either fix up the string to match Erlang's syntax before passing it to list_to_integer (which is what you're already doing) or write your own stand-alone conversion code. I'd usually do the latter. (*) Apart from syntax Erlang's floats are restricted to "finite" values: infinities and NaNs are not permitted anywhere. I don't approve of this restriction, but it's there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deniskononenko@REDACTED Thu May 2 11:07:59 2019 From: deniskononenko@REDACTED (=?UTF-8?B?0JTQtdC90LjRgSDQmtC+0L3QvtC90LXQvdC60L4=?=) Date: Thu, 2 May 2019 14:07:59 +0500 Subject: [erlang-questions] QNX + Erlang R18 Message-ID: Hello! I'm try build Erlang R18 for QNX My steps: 1 ./configure enable-bootstrap-only 2 make success erl_xcomp_sysroot=/opt/qnx650/target/qnx6 ./configure without-javac without-termcap disable-hipe host=XXXX build=YYY make make releas RELEASE_ROOT=.... success copy result to the host system ./Install -minimal .... success /opt/otp18.3/bin/erl Failed to create main carrier for temp_alloc Abort (core dumped) dump file not found PS uname -a QNX localhost 6.5.0 2014/05/29-14:45:50EDT x86pc x86 -------------- next part -------------- An HTML attachment was scrubbed... URL: From deniskononenko@REDACTED Thu May 2 12:16:34 2019 From: deniskononenko@REDACTED (=?UTF-8?B?0JTQtdC90LjRgSDQmtC+0L3QvtC90LXQvdC60L4=?=) Date: Thu, 2 May 2019 15:16:34 +0500 Subject: [erlang-questions] QNX + R18 Message-ID: Hello! I'm try build Erlang R18 for QNX My steps: 1 ./configure enable-bootstrap-only 2 make success erl_xcomp_sysroot=/opt/qnx650/target/qnx6 ./configure without-javac without-termcap disable-hipe host=XXXX build=YYY make make releas RELEASE_ROOT=.... success copy result to the host system ./Install -minimal .... success /opt/otp18.3/bin/erl Failed to create main carrier for temp_alloc Abort (core dumped) dump file not found PS uname -a QNX localhost 6.5.0 2014/05/29-14:45:50EDT x86pc x86 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu May 2 13:34:17 2019 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 2 May 2019 13:34:17 +0200 Subject: [erlang-questions] QNX + Erlang R18 In-Reply-To: References: Message-ID: On Thu, May 2, 2019 at 11:11 AM ????? ????????? wrote: > Hello! > I'm try build Erlang R18 for QNX > > My steps: > 1 ./configure enable-bootstrap-only > 2 make > success > > erl_xcomp_sysroot=/opt/qnx650/target/qnx6 ./configure without-javac > without-termcap disable-hipe host=XXXX build=YYY > make > make releas RELEASE_ROOT=.... > success > copy result to the host system > > ./Install -minimal .... > success > > /opt/otp18.3/bin/erl > > Failed to create main carrier for temp_alloc > > Abort (core dumped) > I would guess that this is because mmap does not work as Erlang wants it to work. I would suggest using strace (or similar tool) to see what syscalls are made and see what the calls to mmap returns. You could also try to disable the Erlang memory manager and fallback to malloc by using "erl +Meamin". > > dump file not found > > > PS > > uname -a > > QNX localhost 6.5.0 2014/05/29-14:45:50EDT x86pc x86 > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empro2@REDACTED Thu May 2 15:16:36 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Thu, 2 May 2019 15:16:36 +0200 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <2488191.ISzvMvNNWm@takoyaki> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> <2488191.ISzvMvNNWm@takoyaki> Message-ID: <20190502151620.13b5bc2a@raspy> Please > Contemplate the following carefully: On Wed, 01 May 2019 16:34:15 +0900 zxq9@REDACTED wrote: > Your trying to put 24930 into a space that can hold a max > value of 255. Your use of the symbol "Your" made me run full speed into the full stop and spend a brief period backtracking and inferring replacement of "Your" (bound to 'second person possessive') with "You're" or "You are", because otherwise your sentence only noun phrase :-) Michael -- That which was said, is not that which was spoken, but that which was understood; and none of these comes necessarily close to that which was meant. From dieter@REDACTED Fri May 3 11:51:39 2019 From: dieter@REDACTED (dieter@REDACTED) Date: Fri, 03 May 2019 09:51:39 +0000 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <20190502151620.13b5bc2a@raspy> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> <2488191.ISzvMvNNWm@takoyaki> <20190502151620.13b5bc2a@raspy> Message-ID: <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> "Trying" can be used as a noun, so it makes sense. On the technical part of Craig's examples: I like the erlang bit/binary syntax a lot, it allowed me to parse packet headers of binary socket protocols with (nearly) oneliners, compared to nasty bit-shifting and masking in C. dieter Am Do., Mai 2, 2019 15:17 schrieb empro2@REDACTED: Please Contemplate the following carefully: On Wed, 01 May 2019 16:34:15 +0900 zxq9@REDACTED (mailto:zxq9@REDACTED) wrote: Your trying to put 24930 into a space that can hold a max value of 255. Your use of the symbol "Your" made me run full speed into the full stop and spend a brief period backtracking and inferring replacement of "Your" (bound to 'second person possessive') with "You're" or "You are", because otherwise your sentence only noun phrase :-) Michael -- That which was said, is not that which was spoken, but that which was understood; and none of these comes necessarily close to that which was meant. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) http://erlang.org/mailman/listinfo/erlang-questions (http://erlang.org/mailman/listinfo/erlang-questions) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragomir.aurelian@REDACTED Fri May 3 11:53:01 2019 From: dragomir.aurelian@REDACTED (Aurelian Dragomir) Date: Fri, 3 May 2019 12:53:01 +0300 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> <2488191.ISzvMvNNWm@takoyaki> <20190502151620.13b5bc2a@raspy> <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> Message-ID: Yes On Fri, May 3, 2019, 12:51 wrote: > "Trying" can be used as a noun, so it makes sense. > > On the technical part of Craig's examples: > I like the erlang bit/binary syntax a lot, it allowed me to parse packet > headers of binary socket protocols > with (nearly) oneliners, compared to nasty bit-shifting and masking in C. > > dieter > > Am Do., Mai 2, 2019 15:17 schrieb empro2@REDACTED: > > Please > > Contemplate the following carefully: > > > > On Wed, 01 May 2019 16:34:15 +0900 > zxq9@REDACTED wrote: > > Your trying to put 24930 into a space that can hold a max > value of 255. > > > > Your use of the symbol "Your" made me run full speed into > the full stop and spend a brief period backtracking and > inferring replacement of "Your" (bound to 'second person > possessive') with "You're" or "You are", because > otherwise your sentence only noun phrase :-) > > Michael > > -- > > That which was said, is not that which was spoken, > but that which was understood; and none of these > comes necessarily close to that which was meant. > > _______________________________________________ > 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 vfordos@REDACTED Fri May 3 15:09:36 2019 From: vfordos@REDACTED (Viktoria Fordos (vfordos)) Date: Fri, 3 May 2019 13:09:36 +0000 Subject: [erlang-questions] LAST CALL FOR PAPERS: Erlang Workshop 2019 -- Deadline: 10 May 2019 Message-ID: <02E18753-F756-4B49-BF1B-1B777747C70E@cisco.com> Technical, practice, and application papers related to Erlang, BEAM, Elixir, Scala/Akka, CloudHaskell, Lisp Flavoured Erlang, OCaml, and functional programming are welcome and encouraged. LAST CALL FOR PAPERS Eighteenth ACM SIGPLAN Erlang Workshop https://icfp19.sigplan.org/home/erlang-2019 Berlin, Germany, 18 August 2019 Satellite event of the 24th ACM SIGPLAN International Conference on Functional Programming (ICFP 2019) 18 - 23 August, 2019 The Erlang Workshop aims to bring together the open source, academic, and industrial communities of Erlang, to discuss technologies and languages related to Erlang. The Erlang model of concurrent programming has been widely emulated, for example by Akka in Scala, and even new programming languages were designed atop of the Erlang VM, such as Elixir. Therefore we would like to broaden the scope of the workshop to include systems like those mentioned above. The workshop will enable participants to familiarize themselves with recent developments on new techniques and tools, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang, Erlang-like languages, functional programming, distribution, concurrency etc. We invite two types of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). Submission related to Erlang, Elixir, Scala/Akka, CloudHaskell, Lisp Flavoured Erlang, OCaml, and functional programming are welcome and encouraged. The maximum length for technical papers is restricted to 12 pages, but short papers (max. 6 pages) are welcomed as well. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 12 pages, but short papers (max. 6 pages) are welcomed as well. Workshop Co-Chairs Adrian Francalanza, University of Malta, Malta Vikt?ria F?rd?s, Cisco Systems, Sweden Program Committee (Note: the Workshop Co-Chairs are also committee members) Annette Bieniusa, University of Kaiserslautern, Germany Christopher S. Meiklejohn, Carnegie Mellon University, USA Clara Benac Earle, Universidad Politecnica de Madrid, Spain Claudio Antares Mezzina, IMT Lucca, Italy Emilio Tuosto, University of Leicester, UK Felix Mulder, Klarna AB, Sweden Francesco Cesarini, Erlang Solutions Ltd, UK Julien Lange, University of Kent, UK Kenji Rikitake, KRPEO, Japan Melinda T?th, ELTE E?tv?s Lor?nd University, Hungary Natalia Chechina, Bournemouth University, UK Rumyana Neykova, Brunel University, UK Scott Lystig Fritchie, Wallaroo, USA Thomas Arts, Quviq AB, Sweden Torben Hoffmann, Alert Logic, Denmark Important Dates Submission deadline: Fri May 10, 2019 Author notification: Fri June 7, 2019 Final submission for the publisher: Sun June 30, 2019 Workshop date: Sun August 18, 2019 Instructions to authors Papers must be submitted online via HotCRP (via the "Erlang2019" event). The submission page is https://erlang19.hotcrp.com Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Paper submissions will be considered for poster submission in the case they are not accepted as full papers. Venue & Registration Details For registration, please see the ICFP 2019 web site at: http://icfp19.sigplan.org/ Related Links ICFP 2019 web site: http://icfp19.sigplan.org/ Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/ Open Source Erlang: http://www.erlang.org/ HotCRP submission site: https://erlang19.hotcrp.com Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Attendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/CodeOfConduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From empro2@REDACTED Sat May 4 01:24:25 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Sat, 4 May 2019 01:24:25 +0200 Subject: [erlang-questions] Help Message-ID: <20190504012425.5650d399@raspy> Provocative subject? Yes, of course, but also no, as you will soon discover when you stick the following text into your head (phrasing is impudent parody of a line delivered by Black Adder II): First my apologies for appearing trollish again; obviously it was not that obvious that this was no superfluous correction but meant to hint at something larger and to split off a thread. But it was not completely off topic: We hone every *bit* when expressing ourselves to silicon-based processors, but when trying to make ourselves understood by carbon-based processors we tend to leave an undue amount of work to them. This does *not* mean that anyone choosing a sub-optimal phrasing or even making a mere typo is sloppy or whatever (This is especially true for people speaking English as a foreign language, as I do). And zxq9 (I hesitate to use first names without previous authorisation, especially in East Asia) is very probably much more fluent and expressive in English than I am, and he certainly is so in Erlang (statement based on having browsed the erlang-questions archive for years (2?) before subscribing). The line was simply a perfect example of how distracting even a small "mistake" can be. *Can* be, was, to me, might be to others, and in a context where every bit counts, too. My intention was to hint at a waste of brain cycles (and a strange dichotomy between programming and spoken languages): * On the first layer people want to implement their vision in Erlang, which requires one or more layers of understanding (depends on complexity). * This requires them to add one more layer where they look up specs. * Often it requires them to add at least one more layer reading and understanding the user guide. * Being thrown into "language analysis mode" by buggy writing takes them one layer further away, and this can be quite a thick layer. The first three take them far from their actual work, but they are more or less necessary (depending on experience). I would simply like people to see how really *help*ful it is to reduce this "unnecessary" last layer. (told you the subject was not merely rethorical :-) We write bugs into our software. We write "bugs" into our writings. We appreciate *help* with debugging our software (the silicon simply being relentless). We get irritated by *help* with debugging our writings?! I do not, and I am suprised again and again by how many people treat programming and spoken languages so differently; do they respect processes running on Si-based hardware more than those running on C-based hardware? Of course, many cases of "text bugs" waste few cycles; many are "debugged" so quickly that they go unnoticed, but they get debugged. Unfortunately even a small waste is multiplied by the number of times it is required, and texts get copied and distributed and served and read and read and read again many times. The idea is to free capacity for complexity on higher levels by reducing complexity on lower levels. It is sad that combining this: Everyone wants to be a language designer. with: The greater the number of people participating in a project, the more its outcome approaches mediocrity. - [I thought this was by D. Knuth, but I cannot track it back to him now; but it does not matter much who said something, more important is what is being said.] we get: spoken languages. Is this of any help to stir interest in debugging texts? This all is only part of musings about how to improve the Erlang documentation, not because it is bad but because it is good enough to deserve being improved. But this is a different story, to be told at a different time ... and in a different thread probably ... Michael -- Normality is merely a question of quantity, not of quality. From empro2@REDACTED Sat May 4 01:40:10 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Sat, 4 May 2019 01:40:10 +0200 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> <2488191.ISzvMvNNWm@takoyaki> <20190502151620.13b5bc2a@raspy> <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> Message-ID: <20190504014010.4a8afc13@raspy> On Fri, 03 May 2019 09:51:39 +0000 dieter@REDACTED wrote: > "Trying" can be used as a noun, True, then it is called a "gerund". > so it makes sense. False, when it was a gerund the line is a sole noun phrase. Here it was meant as a present participle being part of a present progressive but lacking the "are" which got fused to the "You" caused by phonetic similarity or possibly by some electric spelling correction. But that "mistake" in itself was of little importance to me, what was can be found there: > I like the erlang bit/binary syntax a lot, it allowed me So do I. I also liked zxq9's explanation, Erlang (particularly its lack of loops and its "ugliness"), and not least the people on this list :-) Michael -- You do not live in your environment, you are part of it. From jacques.yakoub@REDACTED Sat May 4 20:50:31 2019 From: jacques.yakoub@REDACTED (jacques yakoub) Date: Sat, 4 May 2019 18:50:31 +0000 Subject: [erlang-questions] Profiling code in Erlang Message-ID: Hello, I explored the profiling section of the documentation ( http://erlang.org/doc/efficiency_guide/profiling.html ) and I would like to know how can I get memory usage stats ( for example the module "x" takes *** mb of ram, etc ) Thanks for the help -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Mon May 6 11:51:53 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Mon, 06 May 2019 18:51:53 +0900 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> <20190502151620.13b5bc2a@raspy> <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> Message-ID: <1668347.EdEmeQXeOx@takoyaki> On 2019?5?3???? 9?51?39? JST dieter@REDACTED wrote: > "Trying" can be used as a noun, so it makes sense. > On the technical part of Craig's examples: > I like the erlang bit/binary syntax a lot, it allowed me to parse packet headers of binary socket protocols > with (nearly) oneliners, compared to nasty bit-shifting and masking in C. > dieter Yes, but Michael is right. I had originally started my reply with something like "Your example..." and then changed my approach, edited my sentence, and never properly re-wrote it from the beginning. Whoops! I try to make an effort to write properly because many readers are not native English speakers. Analogous typos (and slang) in Japanese and German occasionally throw me for a loop as well, so I have a lot of sympathy for feelings of annoyance at these kinds of mistakes. Sorry about the confusion! Hopefully the example in Erlang was clearer than my poorly written English. -Craig From sperber@REDACTED Mon May 6 15:25:14 2019 From: sperber@REDACTED (Michael Sperber) Date: Mon, 06 May 2019 15:25:14 +0200 Subject: [erlang-questions] 2nd Call for Contributions: Summer BOB 2019 [Aug 21, Berlin, deadline May 17] Message-ID: Erlang talks are very welcome at BOB! Summer BOB Conference 2019 "What happens when we use what's best for a change?" http://bobkonf.de/2019-summer/cfc.html Berlin, August 21 co-located with ICFP 2019 Call for Contributions Deadline: May 17, 2019 You are engaged in software development or software architecture, and have an interesting story to tell about an advanced tools, technique, language or technology that you're using? Or a gnarly problems that these tools fail to address but should? Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. If you share our vision and want to contribute, submit a proposal for a talk! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). 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 - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - ? 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. We're especially interested in experience reports. Other topics are also relevant, e.g.: - demos and how-tos - reports on problems that cutting-edge languages and tools should address but don't - overviews of a given field 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. 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, ?) - Don't be confused: The system calls a submission event. Submit here ----------- https://bobcfc.active-group.de/bob2019-summer/cfp 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. 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. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: May 17, 2019 - Notification: May 31, 2019 - Program: June 14, 2019 Program Committee ----------------- - 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 More information here: http://bobkonf.de/2019-summer/programmkomitee.html From marc@REDACTED Mon May 6 16:55:15 2019 From: marc@REDACTED (Marc Worrell) Date: Mon, 6 May 2019 16:55:15 +0200 Subject: [erlang-questions] [ANN] Zotonic 0.49.0 released Message-ID: Hi, Zotonic is the Erlang Content Management System and Framework. We have released Zotonic version 0.49.0. This is a maintenance release, focused on security and logging. Breaking backwards compatibility change: ? BC break: Upgraded Bootstrap CSS and JavaScript in mod_admin to 3.4.1; mod_admin no longer ships with a separate Bootstrap instance but uses the one from mod_bootstrap. Any customizations you made to the Bootstrap CSS will therefore be visible in the admin, too. Other changes: ? Logging: the /admin/log changed and now more useful. Events logged include module activation, config changes, rate limiting and ACL changes. ? mod_clamav now also rejects MS Office files with externalLinks directories. This can be turned off using the Zotonic config key clamav_reject_msoffice_external_links ? Uploaded CSV files are now given the mime type text/csv and properly sanitized ? Password reset tokens are now valid for two days. ? mod_linkedin now uses their v2 API See the full release notes at: http://docs.zotonic.com/en/latest/developer-guide/releasenotes/rel_0.49.0.html And download here: https://github.com/zotonic/zotonic/releases Kind regards, The Zotonic Core team. http://zotonic.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From empro2@REDACTED Mon May 6 21:27:35 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Mon, 6 May 2019 21:27:35 +0200 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <1668347.EdEmeQXeOx@takoyaki> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> <20190502151620.13b5bc2a@raspy> <3c25dc7c7e688d1726e1ce520f613b9f@afterlogic.edis.at> <1668347.EdEmeQXeOx@takoyaki> Message-ID: <20190506212735.37b3f7bb@raspy> On Mon, 06 May 2019 18:51:53 +0900 zxq9@REDACTED wrote: > for a loop as well, so I have a lot of sympathy for > feelings of annoyance at these kinds of mistakes. No annoyance at all on my part: http://erlang.org/pipermail/erlang-questions/2019-May/097865.html > Sorry about the confusion! No need at all, the confusion may well have been limited to one single brain. Asked a friend to read the sentence, asked for the meaning and she had uncounsciously performed the necessary replacement, simply had not read what was written there ... > my poorly written English. Glad I am not the only one who likes to exaggerate. ~Michael -- You do not live in your environment, you are part of it. From lloyd@REDACTED Mon May 6 23:40:48 2019 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 6 May 2019 17:40:48 -0400 (EDT) Subject: [erlang-questions] string:lexeme/s2 - an old man's rant Message-ID: <1557178848.685810263@apps.rackspace.com> Hi, This has come up before with various work-arounds suggested. Apologies for this old-man's rant, but every time I run across the impending death of string:tokens/2 to the glory of string:lexemes/2 my blood pressure rises. I HATE IT. I HATE IT. I HATE IT, not least because the terms lexeme and grapheme are ugly inside-baseball words. Reading the docs, I have to do a Google search to understand what these obscure terms are referring to-- precious time wasted. And with my waning years, I don't have time to waste. Even my spell-checker doesn't recognize them. I get the desirability of welcoming unicode into Erlang. But can't we come up with friendlier nomenclature or, at least revise the docs so they don't sound like copy-and-paste out a academic linguistics journal? Grrr. 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 soverdor@REDACTED Tue May 7 00:35:06 2019 From: soverdor@REDACTED (Sam Overdorf) Date: Mon, 6 May 2019 15:35:06 -0700 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <1557178848.685810263@apps.rackspace.com> References: <1557178848.685810263@apps.rackspace.com> Message-ID: remember "Occam's razor". I like simple and easy to use myself. Sam On Mon, May 6, 2019 at 2:40 PM wrote: > > Hi, > > This has come up before with various work-arounds suggested. Apologies for this old-man's rant, but every time I run across the impending death of string:tokens/2 to the glory of string:lexemes/2 my blood pressure rises. > > I HATE IT. I HATE IT. I HATE IT, not least because the terms lexeme and grapheme are ugly inside-baseball words. Reading the docs, I have to do a Google search to understand what these obscure terms are referring to-- precious time wasted. And with my waning years, I don't have time to waste. > > Even my spell-checker doesn't recognize them. > > I get the desirability of welcoming unicode into Erlang. But can't we come up with friendlier nomenclature or, at least revise the docs so they don't sound like copy-and-paste out a academic linguistics journal? > > Grrr. > > 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 hugo@REDACTED Tue May 7 09:56:01 2019 From: hugo@REDACTED (Hugo Mills) Date: Tue, 7 May 2019 07:56:01 +0000 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <1557178848.685810263@apps.rackspace.com> References: <1557178848.685810263@apps.rackspace.com> Message-ID: <20190507075601.GI5426@carfax.org.uk> On Mon, May 06, 2019 at 05:40:48PM -0400, lloyd@REDACTED wrote: > Hi, > > This has come up before with various work-arounds suggested. Apologies for this old-man's rant, but every time I run across the impending death of string:tokens/2 to the glory of string:lexemes/2 my blood pressure rises. > > I HATE IT. I HATE IT. I HATE IT, not least because the terms lexeme and grapheme are ugly inside-baseball words. Reading the docs, I have to do a Google search to understand what these obscure terms are referring to-- precious time wasted. And with my waning years, I don't have time to waste. > > Even my spell-checker doesn't recognize them. > > I get the desirability of welcoming unicode into Erlang. But can't we come up with friendlier nomenclature or, at least revise the docs so they don't sound like copy-and-paste out a academic linguistics journal? Most of the other words you might want to use are already in use for other things. Modern (computer) representation of writing systems is complicated, and there's not enough words to go round the existing concepts. Particularly words without well-known and either misleading or overly-narrow definitions -- see my comment on "letters", below. For the two particular words you're complaining of here, I think of them thus: graphemes, like graphology(*), are to do with the way that something's written on the page -- the shape and composition of the symbols. It's essentially a letter plus all of its diacritics (but it's not defined as such, because there are some graphemes that are ligatures of two or more letters, and some languages where each grapheme is a word in its own right). lexemes, like a lexicon, are to do with words, and are therefore groups of (certain kinds of) graphemes. Hugo. (*) For all that it's unsubstantiated in its psychometric claims. -- Hugo Mills | I can't foretell the future, I just work there. hugo@REDACTED carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | The Doctor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From otp@REDACTED Tue May 7 10:55:21 2019 From: otp@REDACTED (Erlang/OTP) Date: Tue, 7 May 2019 10:55:21 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8 Released Message-ID: <20190507085520.GA55005@erix.ericsson.se> Patch Package: OTP 21.3.8 Git Tag: OTP-21.3.8 Date: 2019-05-07 Trouble Report Id: OTP-14746, OTP-15295, OTP-15717, OTP-15758, OTP-15781, OTP-15785, OTP-15793, OTP-15802 Seq num: ERIERL-143, ERIERL-334, ERIERL-337, ERIERL-342, ERIERL-356, ERL-893, ERL-929, ERL-934 System: OTP Release: 21 Application: common_test-1.17.2, eldap-1.2.7, erl_interface-3.11.3, erts-10.3.5, public_key-1.6.6, ssl-9.2.3, stdlib-3.8.2 Predecessor: OTP 21.3.7 Check out the git tag OTP-21.3.8, 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. --------------------------------------------------------------------- --- POTENTIAL INCOMPATIBILITIES ------------------------------------- --------------------------------------------------------------------- OTP-15717 Application(s): common_test Related Id(s): ERIERL-334 The test result when a hook function fails is in general the same as if the function that the hook is associated with fails. For example, if post_init_per_testcase fails the result is that the test case is skipped, as is the case when init_per_testcase fails.This, however, was earlier not true for timetrap timeouts or other error situations where the process running the hook function was killed. This is now corrected, so the error handling should be the same no matter how the hook function fails. --------------------------------------------------------------------- --- common_test-1.17.2 ---------------------------------------------- --------------------------------------------------------------------- The common_test-1.17.2 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15717 Application(s): common_test Related Id(s): ERIERL-334 *** POTENTIAL INCOMPATIBILITY *** The test result when a hook function fails is in general the same as if the function that the hook is associated with fails. For example, if post_init_per_testcase fails the result is that the test case is skipped, as is the case when init_per_testcase fails.This, however, was earlier not true for timetrap timeouts or other error situations where the process running the hook function was killed. This is now corrected, so the error handling should be the same no matter how the hook function fails. OTP-15758 Application(s): common_test Related Id(s): ERIERL-342 In some rare cases, when two common_test nodes used the same log directory, a timing problem could occur which caused common_test to crash because it's log cache file was unexpectedly empty. This is now corrected. --- Improvements and New Features --- OTP-14746 Application(s): common_test Related Id(s): ERIERL-143 Two new common_test hook functions are introduced: post_groups/2, which is called after Suite:groups/0 post_all/3, which is called after Suite:all/0 These functions allow modifying the return values from the groups/0 and all/0 functions, respectively. A new term, {testcase,TestCase,RepeatProperties} is now also allowed in the return from all/0. This can be used for repeating a single test case a specific number of times, or until it fails or succeeds once. Full runtime dependencies of common_test-1.17.2: compiler-6.0, crypto-3.6, debugger-4.1, erts-7.0, ftp-1.0.0, inets-6.0, kernel-4.0, observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, ssh-4.0, stdlib-3.5, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 --------------------------------------------------------------------- --- eldap-1.2.7 ----------------------------------------------------- --------------------------------------------------------------------- The eldap-1.2.7 application can be applied independently of other applications on a full OTP 21 installation. --- Improvements and New Features --- OTP-15785 Application(s): eldap, public_key, ssl Related Id(s): ERL-893, ERL-929, PR-2215 Back port of bug fix ERL-893 from OTP-22 and document enhancements that will solve dialyzer warnings for users of the ssl application. This change also affects public_key, eldap (and inet doc). Full runtime dependencies of eldap-1.2.7: asn1-3.0, erts-6.0, kernel-3.0, ssl-5.3.4, stdlib-2.0 --------------------------------------------------------------------- --- erl_interface-3.11.3 -------------------------------------------- --------------------------------------------------------------------- The erl_interface-3.11.3 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15781 Application(s): erl_interface Related Id(s): ERIERL-356 erl_interface/ei refused to use node names with an alive name (the part of the node name preceding the @ sign) longer than 63 characters and a host name longer than 64 characters. The total amount of characters allowed in a node name (alivename@REDACTED) was thus limited to 128 characters. These limits applied both to the own node name as well as node names of other nodes. Ordinary Erlang nodes limit the node name length to 256 characters, which meant that you could not communicate with certain Erlang nodes due to their node name used. erl_interface/ei now allow the total amount of characters in a node name to be up to 256 characters. These characters may be distributed between alive name and host name in whatever way needed. That is, the maximum amount of characters in the alive name may be 254 and the maximum amount of characters in the host name may be 254, but in total the node name must not exceed 256 characters. --------------------------------------------------------------------- --- erts-10.3.5 ----------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.5 application *cannot* be applied independently of other applications on an arbitrary OTP 21 installation. On a full OTP 21 installation, also the following runtime dependencies have to be satisfied: -- kernel-6.1 (first satisfied in OTP 21.1) -- sasl-3.3 (first satisfied in OTP 21.2) --- Fixed Bugs and Malfunctions --- OTP-15793 Application(s): erts Related Id(s): ERIERL-337, OTP-15709 Fixed more bugs in process_info(reductions) causing it to sometimes behave non-monotonic. That is, a subsequent call toward the same process could return a lower reduction value. Full runtime dependencies of erts-10.3.5: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- public_key-1.6.6 ------------------------------------------------ --------------------------------------------------------------------- The public_key-1.6.6 application can be applied independently of other applications on a full OTP 21 installation. --- Improvements and New Features --- OTP-15785 Application(s): eldap, public_key, ssl Related Id(s): ERL-893, ERL-929, PR-2215 Back port of bug fix ERL-893 from OTP-22 and document enhancements that will solve dialyzer warnings for users of the ssl application. This change also affects public_key, eldap (and inet doc). Full runtime dependencies of public_key-1.6.6: asn1-3.0, crypto-3.8, erts-6.0, kernel-3.0, stdlib-3.5 --------------------------------------------------------------------- --- ssl-9.2.3 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.2.3 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15802 Application(s): ssl Related Id(s): ERL-934 Missing check of size of user_data_buffer made internal socket behave as an active socket instead of active N. This could cause memory problems. --- Improvements and New Features --- OTP-15785 Application(s): eldap, public_key, ssl Related Id(s): ERL-893, ERL-929, PR-2215 Back port of bug fix ERL-893 from OTP-22 and document enhancements that will solve dialyzer warnings for users of the ssl application. This change also affects public_key, eldap (and inet doc). Full runtime dependencies of ssl-9.2.3: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --- stdlib-3.8.2 ---------------------------------------------------- --------------------------------------------------------------------- The stdlib-3.8.2 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15295 Application(s): stdlib A bug in gen_statem has been fixed where the internal timeout message could arrive as an info to the callback module during high load due to incorrect use of asynchronous timer cancel. Full runtime dependencies of stdlib-3.8.2: compiler-5.0, crypto-3.3, erts-10.0, kernel-6.0, sasl-3.0 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From essen@REDACTED Tue May 7 12:49:19 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 7 May 2019 12:49:19 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8 Released In-Reply-To: <20190507085520.GA55005@erix.ericsson.se> References: <20190507085520.GA55005@erix.ericsson.se> Message-ID: <033034c1-01a9-ab31-a173-0d97e9c765f4@ninenines.eu> Hello, Warning! Something's wrong with this release: https://bugs.erlang.org/browse/ERL-938 On 07/05/2019 10:55, Erlang/OTP wrote: > Patch Package: OTP 21.3.8 > Git Tag: OTP-21.3.8 > Date: 2019-05-07 > Trouble Report Id: OTP-14746, OTP-15295, OTP-15717, OTP-15758, > OTP-15781, OTP-15785, OTP-15793, OTP-15802 > Seq num: ERIERL-143, ERIERL-334, ERIERL-337, > ERIERL-342, ERIERL-356, ERL-893, ERL-929, > ERL-934 > System: OTP > Release: 21 > Application: common_test-1.17.2, eldap-1.2.7, > erl_interface-3.11.3, erts-10.3.5, > public_key-1.6.6, ssl-9.2.3, stdlib-3.8.2 > Predecessor: OTP 21.3.7 > > Check out the git tag OTP-21.3.8, 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. > > --------------------------------------------------------------------- > --- POTENTIAL INCOMPATIBILITIES ------------------------------------- > --------------------------------------------------------------------- > > OTP-15717 Application(s): common_test > Related Id(s): ERIERL-334 > > The test result when a hook function fails is in > general the same as if the function that the hook is > associated with fails. For example, if > post_init_per_testcase fails the result is that the > test case is skipped, as is the case when > init_per_testcase fails.This, however, was earlier not > true for timetrap timeouts or other error situations > where the process running the hook function was killed. > This is now corrected, so the error handling should be > the same no matter how the hook function fails. > > > --------------------------------------------------------------------- > --- common_test-1.17.2 ---------------------------------------------- > --------------------------------------------------------------------- > > The common_test-1.17.2 application can be applied independently of > other applications on a full OTP 21 installation. > > --- Fixed Bugs and Malfunctions --- > > OTP-15717 Application(s): common_test > Related Id(s): ERIERL-334 > > *** POTENTIAL INCOMPATIBILITY *** > > The test result when a hook function fails is in > general the same as if the function that the hook is > associated with fails. For example, if > post_init_per_testcase fails the result is that the > test case is skipped, as is the case when > init_per_testcase fails.This, however, was earlier not > true for timetrap timeouts or other error situations > where the process running the hook function was killed. > This is now corrected, so the error handling should be > the same no matter how the hook function fails. > > > OTP-15758 Application(s): common_test > Related Id(s): ERIERL-342 > > In some rare cases, when two common_test nodes used the > same log directory, a timing problem could occur which > caused common_test to crash because it's log cache file > was unexpectedly empty. This is now corrected. > > > --- Improvements and New Features --- > > OTP-14746 Application(s): common_test > Related Id(s): ERIERL-143 > > Two new common_test hook functions are introduced: > > post_groups/2, which is called after Suite:groups/0 > post_all/3, which is called after Suite:all/0 > > These functions allow modifying the return values from > the groups/0 and all/0 functions, respectively. > > A new term, {testcase,TestCase,RepeatProperties} is now > also allowed in the return from all/0. This can be used > for repeating a single test case a specific number of > times, or until it fails or succeeds once. > > > Full runtime dependencies of common_test-1.17.2: compiler-6.0, > crypto-3.6, debugger-4.1, erts-7.0, ftp-1.0.0, inets-6.0, kernel-4.0, > observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, ssh-4.0, > stdlib-3.5, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 > > > --------------------------------------------------------------------- > --- eldap-1.2.7 ----------------------------------------------------- > --------------------------------------------------------------------- > > The eldap-1.2.7 application can be applied independently of other > applications on a full OTP 21 installation. > > --- Improvements and New Features --- > > OTP-15785 Application(s): eldap, public_key, ssl > Related Id(s): ERL-893, ERL-929, PR-2215 > > Back port of bug fix ERL-893 from OTP-22 and document > enhancements that will solve dialyzer warnings for > users of the ssl application. > > This change also affects public_key, eldap (and inet > doc). > > > Full runtime dependencies of eldap-1.2.7: asn1-3.0, erts-6.0, > kernel-3.0, ssl-5.3.4, stdlib-2.0 > > > --------------------------------------------------------------------- > --- erl_interface-3.11.3 -------------------------------------------- > --------------------------------------------------------------------- > > The erl_interface-3.11.3 application can be applied independently of > other applications on a full OTP 21 installation. > > --- Fixed Bugs and Malfunctions --- > > OTP-15781 Application(s): erl_interface > Related Id(s): ERIERL-356 > > erl_interface/ei refused to use node names with an > alive name (the part of the node name preceding the @ > sign) longer than 63 characters and a host name longer > than 64 characters. The total amount of characters > allowed in a node name (alivename@REDACTED) was thus > limited to 128 characters. These limits applied both to > the own node name as well as node names of other nodes. > Ordinary Erlang nodes limit the node name length to 256 > characters, which meant that you could not communicate > with certain Erlang nodes due to their node name used. > > erl_interface/ei now allow the total amount of > characters in a node name to be up to 256 characters. > These characters may be distributed between alive name > and host name in whatever way needed. That is, the > maximum amount of characters in the alive name may be > 254 and the maximum amount of characters in the host > name may be 254, but in total the node name must not > exceed 256 characters. > > > --------------------------------------------------------------------- > --- erts-10.3.5 ----------------------------------------------------- > --------------------------------------------------------------------- > > Note! The erts-10.3.5 application *cannot* be applied independently > of other applications on an arbitrary OTP 21 installation. > > On a full OTP 21 installation, also the following runtime > dependencies have to be satisfied: > -- kernel-6.1 (first satisfied in OTP 21.1) > -- sasl-3.3 (first satisfied in OTP 21.2) > > > --- Fixed Bugs and Malfunctions --- > > OTP-15793 Application(s): erts > Related Id(s): ERIERL-337, OTP-15709 > > Fixed more bugs in process_info(reductions) causing it > to sometimes behave non-monotonic. That is, a > subsequent call toward the same process could return a > lower reduction value. > > > Full runtime dependencies of erts-10.3.5: kernel-6.1, sasl-3.3, > stdlib-3.5 > > > --------------------------------------------------------------------- > --- public_key-1.6.6 ------------------------------------------------ > --------------------------------------------------------------------- > > The public_key-1.6.6 application can be applied independently of > other applications on a full OTP 21 installation. > > --- Improvements and New Features --- > > OTP-15785 Application(s): eldap, public_key, ssl > Related Id(s): ERL-893, ERL-929, PR-2215 > > Back port of bug fix ERL-893 from OTP-22 and document > enhancements that will solve dialyzer warnings for > users of the ssl application. > > This change also affects public_key, eldap (and inet > doc). > > > Full runtime dependencies of public_key-1.6.6: asn1-3.0, crypto-3.8, > erts-6.0, kernel-3.0, stdlib-3.5 > > > --------------------------------------------------------------------- > --- ssl-9.2.3 ------------------------------------------------------- > --------------------------------------------------------------------- > > The ssl-9.2.3 application can be applied independently of other > applications on a full OTP 21 installation. > > --- Fixed Bugs and Malfunctions --- > > OTP-15802 Application(s): ssl > Related Id(s): ERL-934 > > Missing check of size of user_data_buffer made internal > socket behave as an active socket instead of active N. > This could cause memory problems. > > > --- Improvements and New Features --- > > OTP-15785 Application(s): eldap, public_key, ssl > Related Id(s): ERL-893, ERL-929, PR-2215 > > Back port of bug fix ERL-893 from OTP-22 and document > enhancements that will solve dialyzer warnings for > users of the ssl application. > > This change also affects public_key, eldap (and inet > doc). > > > Full runtime dependencies of ssl-9.2.3: crypto-4.2, erts-10.0, > inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 > > > --------------------------------------------------------------------- > --- stdlib-3.8.2 ---------------------------------------------------- > --------------------------------------------------------------------- > > The stdlib-3.8.2 application can be applied independently of other > applications on a full OTP 21 installation. > > --- Fixed Bugs and Malfunctions --- > > OTP-15295 Application(s): stdlib > > A bug in gen_statem has been fixed where the internal > timeout message could arrive as an info to the callback > module during high load due to incorrect use of > asynchronous timer cancel. > > > Full runtime dependencies of stdlib-3.8.2: compiler-5.0, crypto-3.3, > erts-10.0, kernel-6.0, sasl-3.0 > > > --------------------------------------------------------------------- > --------------------------------------------------------------------- > --------------------------------------------------------------------- > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin https://ninenines.eu From raoknz@REDACTED Tue May 7 15:45:17 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Wed, 8 May 2019 01:45:17 +1200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <20190507075601.GI5426@carfax.org.uk> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> Message-ID: Words ending with the morpheme "-eme" generally come from linguistics. In particular, "grapheme" can only be defined with respect to a particular writing system. "In linguistics , a *grapheme* is the smallest unit of a writing system of any given language." For example, in English, "?" is two graphemes, an "e" grapheme, and a "pronounce this vowel separately" grapheme. In other European languages, "e" and "?" are quite separate letters. What Hugo Mills described is not a grapheme but a grapheme *cluster*. We have code unit, code point, glyph, character, grapheme, grapheme cluster, and a bunch of other terms that are pretty much identical in ASCII or ISO 8859 but when you make a serious attempt to encode all the scripts anyone wants to use on a computer, things get horribly complicated. And they get complicated in *language-specific* ways. (Like case conversion. You can't really do case conversion in Unicode without knowing what language you are concerned with.) This always *was* complicated in the real world, but people in Western Europe and the Americas were mostly able to ignore it. (Things got somewhat complicated in NZ where the indigenous language uses a Latin-based script with macrons and where wh and ng count as single letters.) Curiously, in the Unicode 12 standard, "grapheme" is not in the index, but "grapheme base", "grapheme cluster", and "grapheme extender", for example, are. I suspect that the word "grapheme", precisely because it is a language-dependent technical term with some surprising twists, may not be a good word to use here. "Lexeme" is, if anything worse. "A *lexeme* is a unit of lexical meaning that underlies a set of words that are related through inflection. It is a basic abstract unit of meaning, a unit of morphological analysis in linguistics that roughly corresponds to a set of forms taken by a single root word ." That is NOT what it means here. In computing, it basically means "token". But what *does* it mean? In "Now we see it, now we don't." are there two lexemes spelled "we" or is there one "lexeme" with two occurrences? (If you ever meet two linguists in a bar who don't know each other, try asking them what a "word" is. There are at least four different meanings.) "token" has the merit of coming from one half of the type/token distinction. In fact, that's *WHY* they are called tokens. In "Now we see it, now we don't" there is ONE word type "we" which has TWO tokens. So seriously, as someone who has been reading academic linguistics for several decades and has spent more time trying to understand Unicode than is compatible with sanity, I think the OP's objection carries weight. (I said I've been *reading* the stuff. That's not always the same as *understanding* it, and I certainly couldn't *write* like a linguist.) On Tue, 7 May 2019 at 19:56, Hugo Mills wrote: > On Mon, May 06, 2019 at 05:40:48PM -0400, lloyd@REDACTED wrote: > > Hi, > > > > This has come up before with various work-arounds suggested. Apologies > for this old-man's rant, but every time I run across the impending death of > string:tokens/2 to the glory of string:lexemes/2 my blood pressure rises. > > > > I HATE IT. I HATE IT. I HATE IT, not least because the terms lexeme and > grapheme are ugly inside-baseball words. Reading the docs, I have to do a > Google search to understand what these obscure terms are referring to-- > precious time wasted. And with my waning years, I don't have time to waste. > > > > Even my spell-checker doesn't recognize them. > > > > I get the desirability of welcoming unicode into Erlang. But can't we > come up with friendlier nomenclature or, at least revise the docs so they > don't sound like copy-and-paste out a academic linguistics journal? > > > Most of the other words you might want to use are already in use > for other things. Modern (computer) representation of writing systems > is complicated, and there's not enough words to go round the existing > concepts. Particularly words without well-known and either misleading > or overly-narrow definitions -- see my comment on "letters", below. > > For the two particular words you're complaining of here, I think of > them thus: > > graphemes, like graphology(*), are to do with the way that > something's written on the page -- the shape and composition of the > symbols. It's essentially a letter plus all of its diacritics (but > it's not defined as such, because there are some graphemes that are > ligatures of two or more letters, and some languages where each > grapheme is a word in its own right). > > lexemes, like a lexicon, are to do with words, and are therefore > groups of (certain kinds of) graphemes. > > Hugo. > > (*) For all that it's unsubstantiated in its psychometric claims. > > -- > Hugo Mills | I can't foretell the future, I just work there. > hugo@REDACTED carfax.org.uk | > http://carfax.org.uk/ | > PGP: E2AB1DE4 | The > Doctor > _______________________________________________ > 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 May 7 15:53:45 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 7 May 2019 15:53:45 +0200 Subject: [erlang-questions] Maintenance for erlang.org 2019-05-10 16:00 -- 2019-05-11 14:00 CEST Message-ID: <20190507135345.GA9718@erix.ericsson.se> Hi all. erlang.org, i.e http download and mailing lists, documentation search, etc, will be down for the first half of the upcoming weekend (Friday 16:00 through Saturday 14:00 CEST) due to power maintenance work in the building. Sorry for any inconvenience. Best Regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From lloyd@REDACTED Tue May 7 18:04:46 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 7 May 2019 12:04:46 -0400 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> Message-ID: <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> Hi Folks, I?m certainly not smart enough to resolve this issue. But it seems somewhat like the tension between writing software that solves every imaginable problem in the domain and software that solves the immediate problem at hand. We know in the first case that mounting complexity quickly gets out of hand. If I expect users from every one of the 7,000-some-odd living languages to use my web app, then no doubt Unicode beats ASCII hands down. But how should I handle prompts? A 7,000-option case statement maybe? And where do I find the translators? Aside from that, I have no quarrel with Unicode. I?m grateful that it enables my programs to respect many language conventions. But I would much prefer keeping string:tokens/2 in the Erlang string library and renaming string:lexemes/2 to something like string:unicode_tokens/2. If nothing else, this would take a considerable burden off the documentation. But what do I know? All the best, Lloyd Sent from my iPad > On May 7, 2019, at 9:45 AM, Richard O'Keefe wrote: > > Words ending with the morpheme "-eme" generally come from linguistics. > In particular, "grapheme" can only be defined with respect to a > particular writing system. "In linguistics, a grapheme is the smallest unit of a writing system of any given language." For example, in English, > "?" is two graphemes, an "e" grapheme, and a "pronounce this vowel > separately" grapheme. In other European languages, "e" and "?" are > quite separate letters. > > What Hugo Mills described is not a grapheme but a grapheme *cluster*. > > We have code unit, code point, glyph, character, grapheme, grapheme > cluster, and a bunch of other terms that are pretty much identical > in ASCII or ISO 8859 but when you make a serious attempt to encode > all the scripts anyone wants to use on a computer, things get > horribly complicated. And they get complicated in *language-specific* > ways. (Like case conversion. You can't really do case conversion in > Unicode without knowing what language you are concerned with.) This > always *was* complicated in the real world, but people in Western > Europe and the Americas were mostly able to ignore it. (Things got > somewhat complicated in NZ where the indigenous language uses a > Latin-based script with macrons and where wh and ng count as single > letters.) > > Curiously, in the Unicode 12 standard, "grapheme" is not in the index, > but "grapheme base", "grapheme cluster", and "grapheme extender", for > example, are. > > I suspect that the word "grapheme", precisely because it is a > language-dependent technical term with some surprising twists, > may not be a good word to use here. > > "Lexeme" is, if anything worse. "A lexeme is a unit of lexical meaning that > underlies a set of words that are related through inflection. It is a basic > abstract unit of meaning, a unit of morphological analysis in linguistics that > roughly corresponds to a set of forms taken by a single root word." That is > NOT what it means here. In computing, it basically means "token". But what > *does* it mean? In "Now we see it, now we don't." are there two lexemes > spelled "we" or is there one "lexeme" with two occurrences? (If you ever > meet two linguists in a bar who don't know each other, try asking them what > a "word" is. There are at least four different meanings.) > > "token" has the merit of coming from one half of the type/token distinction. > In fact, that's *WHY* they are called tokens. In "Now we see it, now we > don't" there is ONE word type "we" which has TWO tokens. > > So seriously, as someone who has been reading academic linguistics for > several decades and has spent more time trying to understand Unicode than > is compatible with sanity, I think the OP's objection carries weight. > (I said I've been *reading* the stuff. That's not always the same as > *understanding* it, and I certainly couldn't *write* like a linguist.) > > >> On Tue, 7 May 2019 at 19:56, Hugo Mills wrote: >> On Mon, May 06, 2019 at 05:40:48PM -0400, lloyd@REDACTED wrote: >> > Hi, >> > >> > This has come up before with various work-arounds suggested. Apologies for this old-man's rant, but every time I run across the impending death of string:tokens/2 to the glory of string:lexemes/2 my blood pressure rises. >> > >> > I HATE IT. I HATE IT. I HATE IT, not least because the terms lexeme and grapheme are ugly inside-baseball words. Reading the docs, I have to do a Google search to understand what these obscure terms are referring to-- precious time wasted. And with my waning years, I don't have time to waste. >> > >> > Even my spell-checker doesn't recognize them. >> > >> > I get the desirability of welcoming unicode into Erlang. But can't we come up with friendlier nomenclature or, at least revise the docs so they don't sound like copy-and-paste out a academic linguistics journal? >> >> >> Most of the other words you might want to use are already in use >> for other things. Modern (computer) representation of writing systems >> is complicated, and there's not enough words to go round the existing >> concepts. Particularly words without well-known and either misleading >> or overly-narrow definitions -- see my comment on "letters", below. >> >> For the two particular words you're complaining of here, I think of >> them thus: >> >> graphemes, like graphology(*), are to do with the way that >> something's written on the page -- the shape and composition of the >> symbols. It's essentially a letter plus all of its diacritics (but >> it's not defined as such, because there are some graphemes that are >> ligatures of two or more letters, and some languages where each >> grapheme is a word in its own right). >> >> lexemes, like a lexicon, are to do with words, and are therefore >> groups of (certain kinds of) graphemes. >> >> Hugo. >> >> (*) For all that it's unsubstantiated in its psychometric claims. >> >> -- >> Hugo Mills | I can't foretell the future, I just work there. >> hugo@REDACTED carfax.org.uk | >> http://carfax.org.uk/ | >> PGP: E2AB1DE4 | The Doctor >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.browitt@REDACTED Tue May 7 18:19:11 2019 From: ben.browitt@REDACTED (Ben Browitt) Date: Tue, 7 May 2019 19:19:11 +0300 Subject: [erlang-questions] crypto:hmac/3 using hardware acceleration Message-ID: Profiling my server with eprof show that my app spends most of the time on crypto:hmac(sha, Key, Data) while crypto:stream_encrypt/2 using aes_ctr is much faster. This answer [1] says that HMAC_* routines are software based and don't use hardware. The hmac nif seems to use them [2]. Is my resolution correct? Is it possible to use EVP_* functions instead of HMAC_* functions in the nif? [1] https://stackoverflow.com/a/20322002 [2] https://github.com/erlang/otp/blob/master/lib/crypto/c_src/hmac.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From empro2@REDACTED Tue May 7 22:17:34 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Tue, 7 May 2019 22:17:34 +0200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> Message-ID: <20190507221734.3c188749@raspy> On Tue, 7 May 2019 12:04:46 -0400 "Lloyd R. Prentice" wrote: > language conventions. But I would much prefer keeping > string:tokens/2 in the Erlang string library and renaming > string:lexemes/2 to something like > string:unicode_tokens/2. If nothing else, this would take > a considerable burden off the documentation. Both names force meaning onto mere substrings plucked from some string argument chopped to pieces at some separator characters (with `tokens`) or substrings (`lexemes`). The author cannot know what the resulting substrings mean to the user, may be tokens, may be lexemes, may simply be substrings for whatever use substrings might be useful for; the "key=value" strings from a query-string chopped at "&" are neither tokens nor lexemes. I would provide an option to return empty substrings (for counting) or not, instead of imperative `split` and foisting `token` and `lexeme`. This is a good example of things I have been collecting about the documentation (so far I have been brainstorming in my chamber without you): "two or more adjacent separator graphemes clusters in String are treated as one." No-one cares: users looking up the spec want to know whether they get empty substrings or not -- and how: with such an option to one `substring` function they get to know unmediately, as things are one needs to guess from `split` to `token` to `lexeme` or fro. Qizzy! or they employ a text search for "substring" to end up where I would have begun ... (I hope :-) Moreover: why at all treat two adjacent separators specially? And more thinking takes the users further away from whatever they were trying to accomplish ... "Notice that [$\r,$\n] is one grapheme cluster." as is any character list = string? This note drives me to confusion, requires me to step one meta-layer further away from whatever I was trying to implement or design. Did I misunderstand something? Up until here I thought `Newline_separators = [[$\n], [$\r], [$\r, $\n]]`, but now, why mention the obvious ...? "Where, default leading, indicates whether the leading, the trailing or all encounters of SearchPattern will split String." Leading and trailing separators do not really separate, the example (I love examples at specs :-) shows that more probably "first" and "last" are meant. Now who would want to dig up the documentation out of the repo, change, index, commit, push (or whatever), set up a pull request and ... try to remember what they were doing? Reference, with examples (and possibly some *distinct* implementation rationale, if that is the right place) and User Guide are not code (nor code comments, I am starting to grow doubts about all these JavaDoc, erldoc, ...doc thingies). (*Note: "spec" above means 'reference', not the module attribute, I know I should change them ...*) Reference and Guide are to be read by people who do not know what is meant -- code, comments and implementation details are for those who know too much, it is too much effort to change ones view from implementing know-it-all to unknowing user. So some know to little and others too much. Of course, ex nihilo nihil fit, so the documentation needs to be prepared by those who know too much and some wiki could be a good way to get improvements by those who know too little. My! such loads of prose to lay down what is some simple thought in my head ... Sorry! (somehow :-) Now I can possibly throw away the other draft in which I have been collecting and trying to arrange many (all?) of those things mentioned above over the previous months ... :-) ~Michael -- Time is not money, but money is time: life-time people have spent transforming their environment. From empro2@REDACTED Tue May 7 22:32:18 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Tue, 7 May 2019 22:32:18 +0200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> Message-ID: <20190507221734.3c188749@raspy> > My! such loads of prose to lay down what is some simple *lay out ('explain', 'expound', 'express', 'present', ...) ~Michael -- You do not live in the environment, you are part of it. From icfp.publicity@REDACTED Tue May 7 23:03:23 2019 From: icfp.publicity@REDACTED (Sam Tobin-Hochstadt) Date: Tue, 07 May 2019 17:03:23 -0400 Subject: [erlang-questions] PLMW at ICFP: Call for Scholarship Applications (due 17 May) Message-ID: <5cd1f29b4e6fa_fb52aae625c05b8578cd@homer.mail> ACM SIGPLAN Programming Languages Mentoring Workshop Co-located with ICFP'19 PLMW web page: https://icfp19.sigplan.org/home/PLMW-ICFP-2019 The purpose of the programming languages mentoring workshop (PLMW) is to encourage senior undergraduate and early career (first or second year) to pursue careers in programming language research. We are specifically interested in attracting groups who have traditionally not had the opportunity to participate in research in functional programming. This workshop will be a combination of learning about the work being done in several areas of programming language research and mentoring with respect to helping students prepare for graduate school and the rest of their career. We will bring together leaders in programming language research from academia and industry to give talks on the kind of research typically performed after obtaining a Ph.D. The workshop will engage students, specifically interested in programming language research, in a process of imagining how they might contribute to the world. We especially encourage women and underrepresented minority students to attend PLMW. This workshop is part of the activities surrounding ICFP, the International Conference on Functional Programming, and takes place the day before the main conference. One goal of the workshop is to make ICFP conference more accessible to newcomers. We hope that participants will stay through the entire conference. ## Travel Scholarship Applications (Due 17 May) Please fill out this form by 17 May to apply for travel funding. https://forms.gle/QEvBateG7PRywB336 See the PLMW web page for additional details. The workshop registration is open to all. Students with alternative sources of funding are welcome. From lloyd@REDACTED Wed May 8 00:02:08 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 7 May 2019 18:02:08 -0400 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <20190507221734.3c188749@raspy> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> Message-ID: Hi Michael, Your point re users, e.g., documentation consumers, who know too little vs. users who know too much is well taken. Count me in the first bunch. > Both names force meaning onto mere substrings plucked from > some string argument chopped to pieces at some separator > characters (with `tokens`) or substrings (`lexemes`). If I had a god-like wand I?d do a survey of all instances in all computer languages in which the programmer intends to split natural language text into a list at indices that mark the beginning of some predefined sub-segment of the text where that sub segment may recur zero to n times. Yuk! Even trying to describe the problem abstractly gets ugly fast since, as Richard astutely points out, we don?t have terminology we can agree on. Is a ?string? a passage of natural language, an array of bytes, an arrangement of bits irrespective of byte boundaries, an Erlang list, or some other entity? Seems to me that Unicode valiantly wrestles with the problem of mapping analog representations of ?meaning? into digital representation. Problem is that there are countless ways of making analog marks on paper, stone, or what have you. Even the universe of marks used by the 7,000+ living languages is a formidable number. When we try to map these into the digital realm we either shamefully waste memory resources by giving them all equal length, or we?re forced to deal with the nasty problem of determining where one mark ends and the next begins in our digital space. ASCII solves this problem quite elegantly at the price of excluding much of the world?s population. Unicode is far more inclusive at the price of greater code complexity and muddled discourse re naming of parts. You pay you money and you take your choice. I?m arguing for choice. Keep the simple ASCII-based string functions in the Erlang string library and either create a separate Unicode library or provide Unicode string functions with with more suggestive/evocative names. All the best, Lloyd P.S. Michael? I?m all for clearer documentation with illustrative examples. Sent from my iPad > On May 7, 2019, at 4:17 PM, wrote: > > Both names force meaning onto mere substrings plucked from > some string argument chopped to pieces at some separator > characters (with `tokens`) or substrings (`lexemes`). From raoknz@REDACTED Wed May 8 00:53:25 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Wed, 8 May 2019 10:53:25 +1200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <20190507221734.3c188749@raspy> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> Message-ID: For what it's worth, in Unicode, Line Separator and Paragraph Separator are the recommended characters, with CR, LF, CR+LF, and of arguably NEL (U+0085) being "legacy". Again for what it's worth, Unicode defines an algorithm for breaking text into word( token)s. On Wed, 8 May 2019 at 08:17, wrote: > On Tue, 7 May 2019 12:04:46 -0400 > "Lloyd R. Prentice" wrote: > > > language conventions. But I would much prefer keeping > > string:tokens/2 in the Erlang string library and renaming > > string:lexemes/2 to something like > > string:unicode_tokens/2. If nothing else, this would take > > a considerable burden off the documentation. > > Both names force meaning onto mere substrings plucked from > some string argument chopped to pieces at some separator > characters (with `tokens`) or substrings (`lexemes`). > > The author cannot know what the resulting substrings mean to > the user, may be tokens, may be lexemes, may simply be > substrings for whatever use substrings might be useful > for; the "key=value" strings from a query-string chopped at > "&" are neither tokens nor lexemes. > > I would provide an option to return empty substrings (for > counting) or not, instead of imperative `split` and > foisting `token` and `lexeme`. > > This is a good example of things I have been collecting > about the documentation (so far I have been brainstorming > in my chamber without you): > > "two or more adjacent separator graphemes clusters > in String are treated as one." > > No-one cares: users looking up the spec want to know > whether they get empty substrings or not -- and how: > with such an option to one `substring` function they > get to know unmediately, as things are one needs to guess > from `split` to `token` to `lexeme` or fro. Qizzy! or they > employ a text search for "substring" to end up where I > would have begun ... (I hope :-) > > Moreover: why at all treat two adjacent separators > specially? And more thinking takes the users further away > from whatever they were trying to accomplish ... > > > "Notice that [$\r,$\n] is one grapheme cluster." > > as is any character list = string? This note drives me to > confusion, requires me to step one meta-layer further away > from whatever I was trying to implement or design. Did I > misunderstand something? Up until here I thought > `Newline_separators = [[$\n], [$\r], [$\r, $\n]]`, but > now, why mention the obvious ...? > > > "Where, default leading, indicates whether the > leading, the trailing or all encounters of > SearchPattern will split String." > > Leading and trailing separators do not really separate, the > example (I love examples at specs :-) shows that more > probably "first" and "last" are meant. Now who would want > to dig up the documentation out of the repo, change, index, > commit, push (or whatever), set up a pull request and ... > try to remember what they were doing? Reference, with > examples (and possibly some *distinct* implementation > rationale, if that is the right place) and User Guide are > not code (nor code comments, I am starting to grow doubts > about all these JavaDoc, erldoc, ...doc thingies). > > (*Note: "spec" above means 'reference', not the module > attribute, I know I should change them ...*) > > Reference and Guide are to be read by people who do not > know what is meant -- code, comments and implementation > details are for those who know too much, it is too much > effort to change ones view from implementing know-it-all > to unknowing user. So some know to little and others too > much. Of course, ex nihilo nihil fit, so the documentation > needs to be prepared by those who know too much and some > wiki could be a good way to get improvements by those who > know too little. > > My! such loads of prose to lay down what is some simple > thought in my head ... Sorry! (somehow :-) > > Now I can possibly throw away the other draft in which I > have been collecting and trying to arrange many (all?) of > those things mentioned above over the previous > months ... :-) > > ~Michael > > -- > > Time is not money, but money is time: life-time people have > spent transforming their environment. > > > > > > > > > _______________________________________________ > 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 Wed May 8 01:40:07 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 7 May 2019 19:40:07 -0400 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> Message-ID: <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> Hi Richard, Thanks for clarifying the inner workings of Unicode. Which makes me wonder?- If string:tokens/2 and string:lexemes/2 are functionally identical, or at least substitutable, why not change the implementation of string:tokens/2 to accommodate Unicode, leave the function name alone, and announce to the world that as of Erlang Version XX the implementation of string:tokens/2 has been changed to accommodate Unicode? Then we don?t have to worry about revising legacy code at some point in the future. Yes, I understand that the legacy code might have to be recompiled under the new version of Erlang in the case Unicode becomes universal. But that seems to me a smaller price than revising source code. A simple example that I ran into yesterday while proofreading Build It with Nitrogen, the book that Jesse Gumm and I have been working on for far too long now: We used the function string:tokens/2 moons ago to parse a date string in the form ?04/07/19?. String:tokens/2 was in good standing when we wrote the chapter. Had we published the book in a timely fashion, our readers today might think, oh this book is no good. It uses obsolete functions. I could have changed the function to string:lexemes/2. But if my mind goes tilt when I look at the documentation, what can I expect of my readers? I ended up changing it to re:split/3. All the best, Lloyd Sent from my iPad > On May 7, 2019, at 6:53 PM, Richard O'Keefe wrote: > > For what it's worth, in Unicode, Line Separator and Paragraph > Separator are the recommended characters, with CR, LF, CR+LF, > and of arguably NEL (U+0085) being "legacy". > > Again for what it's worth, Unicode defines an algorithm for > breaking text into word( token)s. > >> On Wed, 8 May 2019 at 08:17, wrote: >> On Tue, 7 May 2019 12:04:46 -0400 >> "Lloyd R. Prentice" wrote: >> >> > language conventions. But I would much prefer keeping >> > string:tokens/2 in the Erlang string library and renaming >> > string:lexemes/2 to something like >> > string:unicode_tokens/2. If nothing else, this would take >> > a considerable burden off the documentation. >> >> Both names force meaning onto mere substrings plucked from >> some string argument chopped to pieces at some separator >> characters (with `tokens`) or substrings (`lexemes`). >> >> The author cannot know what the resulting substrings mean to >> the user, may be tokens, may be lexemes, may simply be >> substrings for whatever use substrings might be useful >> for; the "key=value" strings from a query-string chopped at >> "&" are neither tokens nor lexemes. >> >> I would provide an option to return empty substrings (for >> counting) or not, instead of imperative `split` and >> foisting `token` and `lexeme`. >> >> This is a good example of things I have been collecting >> about the documentation (so far I have been brainstorming >> in my chamber without you): >> >> "two or more adjacent separator graphemes clusters >> in String are treated as one." >> >> No-one cares: users looking up the spec want to know >> whether they get empty substrings or not -- and how: >> with such an option to one `substring` function they >> get to know unmediately, as things are one needs to guess >> from `split` to `token` to `lexeme` or fro. Qizzy! or they >> employ a text search for "substring" to end up where I >> would have begun ... (I hope :-) >> >> Moreover: why at all treat two adjacent separators >> specially? And more thinking takes the users further away >> from whatever they were trying to accomplish ... >> >> >> "Notice that [$\r,$\n] is one grapheme cluster." >> >> as is any character list = string? This note drives me to >> confusion, requires me to step one meta-layer further away >> from whatever I was trying to implement or design. Did I >> misunderstand something? Up until here I thought >> `Newline_separators = [[$\n], [$\r], [$\r, $\n]]`, but >> now, why mention the obvious ...? >> >> >> "Where, default leading, indicates whether the >> leading, the trailing or all encounters of >> SearchPattern will split String." >> >> Leading and trailing separators do not really separate, the >> example (I love examples at specs :-) shows that more >> probably "first" and "last" are meant. Now who would want >> to dig up the documentation out of the repo, change, index, >> commit, push (or whatever), set up a pull request and ... >> try to remember what they were doing? Reference, with >> examples (and possibly some *distinct* implementation >> rationale, if that is the right place) and User Guide are >> not code (nor code comments, I am starting to grow doubts >> about all these JavaDoc, erldoc, ...doc thingies). >> >> (*Note: "spec" above means 'reference', not the module >> attribute, I know I should change them ...*) >> >> Reference and Guide are to be read by people who do not >> know what is meant -- code, comments and implementation >> details are for those who know too much, it is too much >> effort to change ones view from implementing know-it-all >> to unknowing user. So some know to little and others too >> much. Of course, ex nihilo nihil fit, so the documentation >> needs to be prepared by those who know too much and some >> wiki could be a good way to get improvements by those who >> know too little. >> >> My! such loads of prose to lay down what is some simple >> thought in my head ... Sorry! (somehow :-) >> >> Now I can possibly throw away the other draft in which I >> have been collecting and trying to arrange many (all?) of >> those things mentioned above over the previous >> months ... :-) >> >> ~Michael >> >> -- >> >> Time is not money, but money is time: life-time people have >> spent transforming their environment. >> >> >> >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Wed May 8 02:39:55 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Wed, 8 May 2019 12:39:55 +1200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> Message-ID: Let's look at the documentation for tokens/2: http://erlang.org/doc/man/string.html#tokens-2 The first thing I notice is that we are told *that* the function is obsolete but not *why* it is, and that's important. The second thing I notice is that we are told to use lexemes/2 instead, but we are not told *how* to do that. An example showing an old call and its new equivalent would do wonders. The third thing I notice is the reason that the second thing matters. Consider the following examples: tokens("aaa", "x") => ["aaa"] tokens("aa", "x") => ["aa"] tokens("a", "x") => ["a"] so by continuity we expect tokens("", "x") => [""] BUT the result is actually []. True, the description says that the result is a list of non-empty strings, but I don't really see why that is so important that our natural expectation that tokens(S, [X]) => [X] whenever S is *any* string not containing X should be violated, and if it is, then I would definitely expect an exception. The fourth thing I notice is that the treatment of multi-element separator lists is odd. I have had occasion to use separators with more than one code-point, and for Unicode that could be essential. I have also had occasion to use split at C1, then at C2, then at C3, then at C4, ... I've also had occasion to split on one separator and then split the pieces into smaller pieces, so multiple levels of splitting. (Think of /etc/passwd for a simple example.) But the only time I ever want multiple *alternative* separators is when asking for white-space separation, and *that* is when I want non-empty pieces. It is also the only time I ever want separators coalesced. Given a string like "||x|yy||w" and the separator "|", I've always wanted ["","","x","yy","","w"] as the answer. But there's a particular point here: which of us knows off-hand just what all the Zs, Zl, and Zp characters of Unicode actually are? It would make a *lot* of sense to have tokens(String) -> list of non-empty pieces tokens(String, Sep) -> list of possibly empty pieces separated by the non-empty substring Sep. The fifth thing I notice is that there is no specification of what happens if SeparatorList is empty. All things considered, this is a function I am never going to use, because it is less work to write my own than to try to figure out this documentation. And I had to look at the code to figure some of it out. I get seriously confused by some of the code in string.erl. We find %% Fetch first grapheme cluster .. next_grapheme(CD) -> .. Which is it? Grapheme or grapheme cluster? These are *different* (but overlapping) things! And where is the locale argument so that the function knows what a "user-perceived character" actually *is*? How come an empty list counts as a grapheme_cluster()? What if I have something like "foo:bar::uggle::zoosh" and I want to split it at "::" but NOT at ":"? "::" is not a grapheme cluster,' so it looks like neither of these functions will help me. Writing good documentation is HARD. At dear departed Quintus, we started with a full time technical writer and expanded to three, nearly as many as developers. The *name* 'lexemes' is arguably the *least* confusing thing in the documentation. If it were called z3k_u4y/2 that would increase my confusion very little. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Wed May 8 06:27:41 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Wed, 8 May 2019 00:27:41 -0400 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> Message-ID: <7477D767-9DDC-4036-BDAA-662D3E3B6A45@writersglen.com> Hi Richard, My head spins. I?m ashamed to say that I?m functionally illiterate in every natural language of the world except English? and I?m still working at mastering that. And I program for English speakers. So, I guess I?ll stick with re:split/3 until I have a pressing need for Unicode. Maybe by then the issues will be ironed out? and better, well tucked under the hood. Richard, you?re a star in the Erlang firmament. Thank you, Lloyd Sent from my iPad > On May 7, 2019, at 8:39 PM, Richard O'Keefe wrote: > > Let's look at the documentation for tokens/2: > > http://erlang.org/doc/man/string.html#tokens-2 > > The first thing I notice is that we are told *that* > the function is obsolete but not *why* it is, and > that's important. > > The second thing I notice is that we are told > to use lexemes/2 instead, but we are not told *how* > to do that. An example showing an old call and its > new equivalent would do wonders. > > The third thing I notice is the reason that the > second thing matters. Consider the following > examples: > tokens("aaa", "x") => ["aaa"] > tokens("aa", "x") => ["aa"] > tokens("a", "x") => ["a"] > so by continuity we expect > tokens("", "x") => [""] > BUT the result is actually []. True, the > description says that the result is a list > of non-empty strings, but I don't really see > why that is so important that our natural > expectation that tokens(S, [X]) => [X] > whenever S is *any* string not containing X > should be violated, and if it is, then I > would definitely expect an exception. > > The fourth thing I notice is that the treatment > of multi-element separator lists is odd. I have > had occasion to use separators with more than > one code-point, and for Unicode that could be > essential. I have also had occasion to use > split at C1, then at C2, then at C3, then at C4, ... > I've also had occasion to split on one separator > and then split the pieces into smaller pieces, > so multiple levels of splitting. (Think of > /etc/passwd for a simple example.) But the only > time I ever want multiple *alternative* separators > is when asking for white-space separation, and > *that* is when I want non-empty pieces. It is > also the only time I ever want separators coalesced. > Given a string like "||x|yy||w" and the separator > "|", I've always wanted ["","","x","yy","","w"] > as the answer. But there's a particular point > here: which of us knows off-hand just what all > the Zs, Zl, and Zp characters of Unicode actually > are? It would make a *lot* of sense to have > tokens(String) -> list of non-empty pieces > tokens(String, Sep) -> list of possibly empty > pieces separated by the non-empty substring Sep. > > The fifth thing I notice is that there is no > specification of what happens if SeparatorList is > empty. > > All things considered, this is a function I am never > going to use, because it is less work to write my own > than to try to figure out this documentation. And I > had to look at the code to figure some of it out. > > I get seriously confused by some of the code in > string.erl. We find > %% Fetch first grapheme cluster .. > next_grapheme(CD) -> .. > Which is it? Grapheme or grapheme cluster? These > are *different* (but overlapping) things! And > where is the locale argument so that the function > knows what a "user-perceived character" actually *is*? > How come an empty list counts as a grapheme_cluster()? > > What if I have something like > "foo:bar::uggle::zoosh" and I want to split it at > "::" but NOT at ":"? "::" is not a grapheme cluster,' > so it looks like neither of these functions will help > me. > > Writing good documentation is HARD. At dear departed > Quintus, we started with a full time technical writer > and expanded to three, nearly as many as developers. > > The *name* 'lexemes' is arguably the *least* confusing > thing in the documentation. If it were called z3k_u4y/2 > that would increase my confusion very little. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.r.nilsson@REDACTED Wed May 8 12:06:17 2019 From: hans.r.nilsson@REDACTED (Hans Nilsson R) Date: Wed, 8 May 2019 10:06:17 +0000 Subject: [erlang-questions] crypto:hmac/3 using hardware acceleration In-Reply-To: References: Message-ID: Yes it's possible to use the EVP_* functions. But it is nothing that we plan to do for the moment. But pull-requests are always welcome :) /Hans On Tue, 2019-05-07 at 19:19 +0300, Ben Browitt wrote: Profiling my server with eprof show that my app spends most of the time on crypto:hmac(sha, Key, Data) while crypto:stream_encrypt/2 using aes_ctr is much faster. This answer [1] says that HMAC_* routines are software based and don't use hardware. The hmac nif seems to use them [2]. Is my resolution correct? Is it possible to use EVP_* functions instead of HMAC_* functions in the nif? [1] https://stackoverflow.com/a/20322002 [2] https://github.com/erlang/otp/blob/master/lib/crypto/c_src/hmac.c _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From empro2@REDACTED Wed May 8 12:36:16 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Wed, 8 May 2019 12:36:16 +0200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <7477D767-9DDC-4036-BDAA-662D3E3B6A45@writersglen.com> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> <7477D767-9DDC-4036-BDAA-662D3E3B6A45@writersglen.com> Message-ID: <20190508123616.625b7d32@raspy> On Wed, 8 May 2019 00:27:41 -0400 "Lloyd R. Prentice" wrote: > Richard, you?re a star in the Erlang firmament. Not at all limited to Erlang, not even to all the languages he has ever mentioned; so it is at least the programming languages firmament ... oh, and the unicode firmament, it appears ... I sometimes wonder whether I should eat more kiwis, sorry! kiwi fruit, of course ... then again ... ;-) ~Michael -- If a *bank* in need of money is systematically important, then that system is not important. From empro2@REDACTED Wed May 8 12:49:32 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Wed, 8 May 2019 12:49:32 +0200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> Message-ID: <20190508124932.459547fb@raspy> On Wed, 8 May 2019 12:39:55 +1200 "Richard O'Keefe" wrote: > All things considered, this is a function I am never > going to use, because it is less work to write my own > than to try to figure out this documentation. And I > had to look at the code to figure some of it out. Glad to hear! With all this much appreciated precious effort gone and going into Erlang (including its documentation), I was not sure whether it was merely my own personal stupidity. Well, it still might be, as it is not only `tokens/2` that takes me too far away from coding and designing. > I get seriously confused by some of the code in > string.erl. Who is supposed to believe that?! ;-) Seriously, that would make me shut down everything and take extensive walks before reworking everything ... > Writing good documentation is HARD. At dear departed > Quintus, we started with a full time technical writer > and expanded to three, nearly as many as developers. "Limited resources" was one of the first items on my list. The link in this anniversary posting proved that I had correctly guessed all the points mentioned in it. My basic intention is to somehow generate so much community help that the Erlang/OTP team gets so bored that they go and replace records with frames :-) "What is to become of my life, dreaming days away ...?" ~Michael -- ?Even after a thousand explanations a fool is no wiser, whereas someone intelligent requires only one fourth of these.? ? from the Mah?bh?rata (???????) From ben.browitt@REDACTED Wed May 8 13:15:51 2019 From: ben.browitt@REDACTED (Ben Browitt) Date: Wed, 8 May 2019 14:15:51 +0300 Subject: [erlang-questions] crypto:hmac/3 using hardware acceleration In-Reply-To: References: Message-ID: I've tested the speed with and without evp. evp is slower because Intel cpus don't have hardware acceleration for sha. So it's best to leave it without evp for now. Thanks. openssl speed sha1 openssl speed -evp sha1 On Wed, May 8, 2019 at 1:06 PM Hans Nilsson R wrote: > Yes it's possible to use the EVP_* functions. But it is nothing that we > plan to do for the moment. > > But pull-requests are always welcome :) > > /Hans > > On Tue, 2019-05-07 at 19:19 +0300, Ben Browitt wrote: > > Profiling my server with eprof show that my app spends most of the time > on crypto:hmac(sha, Key, Data) while crypto:stream_encrypt/2 using aes_ctr > is much faster. > > This answer [1] says that HMAC_* routines are software based and don't use > hardware. The hmac nif seems to use them [2]. > > Is my resolution correct? > Is it possible to use EVP_* functions instead of HMAC_* functions in the > nif? > > [1] https://stackoverflow.com/a/20322002 > [2] https://github.com/erlang/otp/blob/master/lib/crypto/c_src/hmac.c > > > _______________________________________________ > > 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 Wed May 8 13:19:18 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Wed, 8 May 2019 13:19:18 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8 Released In-Reply-To: <033034c1-01a9-ab31-a173-0d97e9c765f4@ninenines.eu> References: <20190507085520.GA55005@erix.ericsson.se> <033034c1-01a9-ab31-a173-0d97e9c765f4@ninenines.eu> Message-ID: So? Did we regress? /Frank Hello, > > Warning! Something's wrong with this release: > > https://bugs.erlang.org/browse/ERL-938 > > On 07/05/2019 10:55, Erlang/OTP wrote: > > Patch Package: OTP 21.3.8 > > Git Tag: OTP-21.3.8 > > Date: 2019-05-07 > > Trouble Report Id: OTP-14746, OTP-15295, OTP-15717, OTP-15758, > > OTP-15781, OTP-15785, OTP-15793, OTP-15802 > > Seq num: ERIERL-143, ERIERL-334, ERIERL-337, > > ERIERL-342, ERIERL-356, ERL-893, ERL-929, > > ERL-934 > > System: OTP > > Release: 21 > > Application: common_test-1.17.2, eldap-1.2.7, > > erl_interface-3.11.3, erts-10.3.5, > > public_key-1.6.6, ssl-9.2.3, stdlib-3.8.2 > > Predecessor: OTP 21.3.7 > > > > Check out the git tag OTP-21.3.8, 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. > > > > --------------------------------------------------------------------- > > --- POTENTIAL INCOMPATIBILITIES ------------------------------------- > > --------------------------------------------------------------------- > > > > OTP-15717 Application(s): common_test > > Related Id(s): ERIERL-334 > > > > The test result when a hook function fails is in > > general the same as if the function that the hook is > > associated with fails. For example, if > > post_init_per_testcase fails the result is that the > > test case is skipped, as is the case when > > init_per_testcase fails.This, however, was earlier not > > true for timetrap timeouts or other error situations > > where the process running the hook function was killed. > > This is now corrected, so the error handling should be > > the same no matter how the hook function fails. > > > > > > --------------------------------------------------------------------- > > --- common_test-1.17.2 ---------------------------------------------- > > --------------------------------------------------------------------- > > > > The common_test-1.17.2 application can be applied independently of > > other applications on a full OTP 21 installation. > > > > --- Fixed Bugs and Malfunctions --- > > > > OTP-15717 Application(s): common_test > > Related Id(s): ERIERL-334 > > > > *** POTENTIAL INCOMPATIBILITY *** > > > > The test result when a hook function fails is in > > general the same as if the function that the hook is > > associated with fails. For example, if > > post_init_per_testcase fails the result is that the > > test case is skipped, as is the case when > > init_per_testcase fails.This, however, was earlier not > > true for timetrap timeouts or other error situations > > where the process running the hook function was killed. > > This is now corrected, so the error handling should be > > the same no matter how the hook function fails. > > > > > > OTP-15758 Application(s): common_test > > Related Id(s): ERIERL-342 > > > > In some rare cases, when two common_test nodes used the > > same log directory, a timing problem could occur which > > caused common_test to crash because it's log cache file > > was unexpectedly empty. This is now corrected. > > > > > > --- Improvements and New Features --- > > > > OTP-14746 Application(s): common_test > > Related Id(s): ERIERL-143 > > > > Two new common_test hook functions are introduced: > > > > post_groups/2, which is called after Suite:groups/0 > > post_all/3, which is called after Suite:all/0 > > > > These functions allow modifying the return values from > > the groups/0 and all/0 functions, respectively. > > > > A new term, {testcase,TestCase,RepeatProperties} is now > > also allowed in the return from all/0. This can be used > > for repeating a single test case a specific number of > > times, or until it fails or succeeds once. > > > > > > Full runtime dependencies of common_test-1.17.2: compiler-6.0, > > crypto-3.6, debugger-4.1, erts-7.0, ftp-1.0.0, inets-6.0, kernel-4.0, > > observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, ssh-4.0, > > stdlib-3.5, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 > > > > > > --------------------------------------------------------------------- > > --- eldap-1.2.7 ----------------------------------------------------- > > --------------------------------------------------------------------- > > > > The eldap-1.2.7 application can be applied independently of other > > applications on a full OTP 21 installation. > > > > --- Improvements and New Features --- > > > > OTP-15785 Application(s): eldap, public_key, ssl > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > Back port of bug fix ERL-893 from OTP-22 and document > > enhancements that will solve dialyzer warnings for > > users of the ssl application. > > > > This change also affects public_key, eldap (and inet > > doc). > > > > > > Full runtime dependencies of eldap-1.2.7: asn1-3.0, erts-6.0, > > kernel-3.0, ssl-5.3.4, stdlib-2.0 > > > > > > --------------------------------------------------------------------- > > --- erl_interface-3.11.3 -------------------------------------------- > > --------------------------------------------------------------------- > > > > The erl_interface-3.11.3 application can be applied independently of > > other applications on a full OTP 21 installation. > > > > --- Fixed Bugs and Malfunctions --- > > > > OTP-15781 Application(s): erl_interface > > Related Id(s): ERIERL-356 > > > > erl_interface/ei refused to use node names with an > > alive name (the part of the node name preceding the @ > > sign) longer than 63 characters and a host name longer > > than 64 characters. The total amount of characters > > allowed in a node name (alivename@REDACTED) was thus > > limited to 128 characters. These limits applied both to > > the own node name as well as node names of other nodes. > > Ordinary Erlang nodes limit the node name length to 256 > > characters, which meant that you could not communicate > > with certain Erlang nodes due to their node name used. > > > > erl_interface/ei now allow the total amount of > > characters in a node name to be up to 256 characters. > > These characters may be distributed between alive name > > and host name in whatever way needed. That is, the > > maximum amount of characters in the alive name may be > > 254 and the maximum amount of characters in the host > > name may be 254, but in total the node name must not > > exceed 256 characters. > > > > > > --------------------------------------------------------------------- > > --- erts-10.3.5 ----------------------------------------------------- > > --------------------------------------------------------------------- > > > > Note! The erts-10.3.5 application *cannot* be applied independently > > of other applications on an arbitrary OTP 21 installation. > > > > On a full OTP 21 installation, also the following runtime > > dependencies have to be satisfied: > > -- kernel-6.1 (first satisfied in OTP 21.1) > > -- sasl-3.3 (first satisfied in OTP 21.2) > > > > > > --- Fixed Bugs and Malfunctions --- > > > > OTP-15793 Application(s): erts > > Related Id(s): ERIERL-337, OTP-15709 > > > > Fixed more bugs in process_info(reductions) causing it > > to sometimes behave non-monotonic. That is, a > > subsequent call toward the same process could return a > > lower reduction value. > > > > > > Full runtime dependencies of erts-10.3.5: kernel-6.1, sasl-3.3, > > stdlib-3.5 > > > > > > --------------------------------------------------------------------- > > --- public_key-1.6.6 ------------------------------------------------ > > --------------------------------------------------------------------- > > > > The public_key-1.6.6 application can be applied independently of > > other applications on a full OTP 21 installation. > > > > --- Improvements and New Features --- > > > > OTP-15785 Application(s): eldap, public_key, ssl > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > Back port of bug fix ERL-893 from OTP-22 and document > > enhancements that will solve dialyzer warnings for > > users of the ssl application. > > > > This change also affects public_key, eldap (and inet > > doc). > > > > > > Full runtime dependencies of public_key-1.6.6: asn1-3.0, crypto-3.8, > > erts-6.0, kernel-3.0, stdlib-3.5 > > > > > > --------------------------------------------------------------------- > > --- ssl-9.2.3 ------------------------------------------------------- > > --------------------------------------------------------------------- > > > > The ssl-9.2.3 application can be applied independently of other > > applications on a full OTP 21 installation. > > > > --- Fixed Bugs and Malfunctions --- > > > > OTP-15802 Application(s): ssl > > Related Id(s): ERL-934 > > > > Missing check of size of user_data_buffer made internal > > socket behave as an active socket instead of active N. > > This could cause memory problems. > > > > > > --- Improvements and New Features --- > > > > OTP-15785 Application(s): eldap, public_key, ssl > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > Back port of bug fix ERL-893 from OTP-22 and document > > enhancements that will solve dialyzer warnings for > > users of the ssl application. > > > > This change also affects public_key, eldap (and inet > > doc). > > > > > > Full runtime dependencies of ssl-9.2.3: crypto-4.2, erts-10.0, > > inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 > > > > > > --------------------------------------------------------------------- > > --- stdlib-3.8.2 ---------------------------------------------------- > > --------------------------------------------------------------------- > > > > The stdlib-3.8.2 application can be applied independently of other > > applications on a full OTP 21 installation. > > > > --- Fixed Bugs and Malfunctions --- > > > > OTP-15295 Application(s): stdlib > > > > A bug in gen_statem has been fixed where the internal > > timeout message could arrive as an info to the callback > > module during high load due to incorrect use of > > asynchronous timer cancel. > > > > > > Full runtime dependencies of stdlib-3.8.2: compiler-5.0, crypto-3.3, > > erts-10.0, kernel-6.0, sasl-3.0 > > > > > > --------------------------------------------------------------------- > > --------------------------------------------------------------------- > > --------------------------------------------------------------------- > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > https://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed May 8 13:26:50 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 8 May 2019 13:26:50 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8 Released In-Reply-To: References: <20190507085520.GA55005@erix.ericsson.se> <033034c1-01a9-ab31-a173-0d97e9c765f4@ninenines.eu> Message-ID: Yes. Ingela reacted quickly and did great work with a PR fixing the issue at https://github.com/erlang/otp/pull/2224 Cheers, On 08/05/2019 13:19, Frank Muller wrote: > So? Did we regress? > > /Frank > > Hello, > > Warning! Something's wrong with this release: > > https://bugs.erlang.org/browse/ERL-938 > > On 07/05/2019 10:55, Erlang/OTP wrote: > > Patch Package:? ? ? ? ? ?OTP 21.3.8 > > Git Tag:? ? ? ? ? ? ? ? ?OTP-21.3.8 > > Date:? ? ? ? ? ? ? ? ? ? 2019-05-07 > > Trouble Report Id:? ? ? ?OTP-14746, OTP-15295, OTP-15717, OTP-15758, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?OTP-15781, OTP-15785, OTP-15793, OTP-15802 > > Seq num:? ? ? ? ? ? ? ? ?ERIERL-143, ERIERL-334, ERIERL-337, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?ERIERL-342, ERIERL-356, ERL-893, ERL-929, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?ERL-934 > > System:? ? ? ? ? ? ? ? ? OTP > > Release:? ? ? ? ? ? ? ? ?21 > > Application:? ? ? ? ? ? ?common_test-1.17.2, eldap-1.2.7, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?erl_interface-3.11.3, erts-10.3.5, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?public_key-1.6.6, ssl-9.2.3, stdlib-3.8.2 > > Predecessor:? ? ? ? ? ? ?OTP 21.3.7 > > > >? ?Check out the git tag OTP-21.3.8, 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. > > > > > ?--------------------------------------------------------------------- > >? ?--- POTENTIAL INCOMPATIBILITIES > ------------------------------------- > > > ?--------------------------------------------------------------------- > > > >? ? OTP-15717? ? Application(s): common_test > >? ? ? ? ? ? ? ? ?Related Id(s): ERIERL-334 > > > >? ? ? ? ? ? ? ? ?The test result when a hook function fails is in > >? ? ? ? ? ? ? ? ?general the same as if the function that the hook is > >? ? ? ? ? ? ? ? ?associated with fails. For example, if > >? ? ? ? ? ? ? ? ?post_init_per_testcase fails the result is that the > >? ? ? ? ? ? ? ? ?test case is skipped, as is the case when > >? ? ? ? ? ? ? ? ?init_per_testcase fails.This, however, was > earlier not > >? ? ? ? ? ? ? ? ?true for timetrap timeouts or other error situations > >? ? ? ? ? ? ? ? ?where the process running the hook function was > killed. > >? ? ? ? ? ? ? ? ?This is now corrected, so the error handling > should be > >? ? ? ? ? ? ? ? ?the same no matter how the hook function fails. > > > > > > > ?--------------------------------------------------------------------- > >? ?--- common_test-1.17.2 > ---------------------------------------------- > > > ?--------------------------------------------------------------------- > > > >? ?The common_test-1.17.2 application can be applied independently of > >? ?other applications on a full OTP 21 installation. > > > >? ?--- Fixed Bugs and Malfunctions --- > > > >? ? OTP-15717? ? Application(s): common_test > >? ? ? ? ? ? ? ? ?Related Id(s): ERIERL-334 > > > >? ? ? ? ? ? ? ? ?*** POTENTIAL INCOMPATIBILITY *** > > > >? ? ? ? ? ? ? ? ?The test result when a hook function fails is in > >? ? ? ? ? ? ? ? ?general the same as if the function that the hook is > >? ? ? ? ? ? ? ? ?associated with fails. For example, if > >? ? ? ? ? ? ? ? ?post_init_per_testcase fails the result is that the > >? ? ? ? ? ? ? ? ?test case is skipped, as is the case when > >? ? ? ? ? ? ? ? ?init_per_testcase fails.This, however, was > earlier not > >? ? ? ? ? ? ? ? ?true for timetrap timeouts or other error situations > >? ? ? ? ? ? ? ? ?where the process running the hook function was > killed. > >? ? ? ? ? ? ? ? ?This is now corrected, so the error handling > should be > >? ? ? ? ? ? ? ? ?the same no matter how the hook function fails. > > > > > >? ? OTP-15758? ? Application(s): common_test > >? ? ? ? ? ? ? ? ?Related Id(s): ERIERL-342 > > > >? ? ? ? ? ? ? ? ?In some rare cases, when two common_test nodes > used the > >? ? ? ? ? ? ? ? ?same log directory, a timing problem could occur > which > >? ? ? ? ? ? ? ? ?caused common_test to crash because it's log > cache file > >? ? ? ? ? ? ? ? ?was unexpectedly empty. This is now corrected. > > > > > >? ?--- Improvements and New Features --- > > > >? ? OTP-14746? ? Application(s): common_test > >? ? ? ? ? ? ? ? ?Related Id(s): ERIERL-143 > > > >? ? ? ? ? ? ? ? ?Two new common_test hook functions are introduced: > > > >? ? ? ? ? ? ? ? ?post_groups/2, which is called after Suite:groups/0 > >? ? ? ? ? ? ? ? ?post_all/3, which is called after Suite:all/0 > > > >? ? ? ? ? ? ? ? ?These functions allow modifying the return values > from > >? ? ? ? ? ? ? ? ?the groups/0 and all/0 functions, respectively. > > > >? ? ? ? ? ? ? ? ?A new term, {testcase,TestCase,RepeatProperties} > is now > >? ? ? ? ? ? ? ? ?also allowed in the return from all/0. This can > be used > >? ? ? ? ? ? ? ? ?for repeating a single test case a specific number of > >? ? ? ? ? ? ? ? ?times, or until it fails or succeeds once. > > > > > >? ?Full runtime dependencies of common_test-1.17.2: compiler-6.0, > >? ?crypto-3.6, debugger-4.1, erts-7.0, ftp-1.0.0, inets-6.0, > kernel-4.0, > >? ?observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, > ssh-4.0, > >? ?stdlib-3.5, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 > > > > > > > ?--------------------------------------------------------------------- > >? ?--- eldap-1.2.7 > ----------------------------------------------------- > > > ?--------------------------------------------------------------------- > > > >? ?The eldap-1.2.7 application can be applied independently of other > >? ?applications on a full OTP 21 installation. > > > >? ?--- Improvements and New Features --- > > > >? ? OTP-15785? ? Application(s): eldap, public_key, ssl > >? ? ? ? ? ? ? ? ?Related Id(s): ERL-893, ERL-929, PR-2215 > > > >? ? ? ? ? ? ? ? ?Back port of bug fix ERL-893 from OTP-22 and document > >? ? ? ? ? ? ? ? ?enhancements that will solve dialyzer warnings for > >? ? ? ? ? ? ? ? ?users of the ssl application. > > > >? ? ? ? ? ? ? ? ?This change also affects public_key, eldap (and inet > >? ? ? ? ? ? ? ? ?doc). > > > > > >? ?Full runtime dependencies of eldap-1.2.7: asn1-3.0, erts-6.0, > >? ?kernel-3.0, ssl-5.3.4, stdlib-2.0 > > > > > > > ?--------------------------------------------------------------------- > >? ?--- erl_interface-3.11.3 > -------------------------------------------- > > > ?--------------------------------------------------------------------- > > > >? ?The erl_interface-3.11.3 application can be applied > independently of > >? ?other applications on a full OTP 21 installation. > > > >? ?--- Fixed Bugs and Malfunctions --- > > > >? ? OTP-15781? ? Application(s): erl_interface > >? ? ? ? ? ? ? ? ?Related Id(s): ERIERL-356 > > > >? ? ? ? ? ? ? ? ?erl_interface/ei refused to use node names with an > >? ? ? ? ? ? ? ? ?alive name (the part of the node name preceding the @ > >? ? ? ? ? ? ? ? ?sign) longer than 63 characters and a host name > longer > >? ? ? ? ? ? ? ? ?than 64 characters. The total amount of characters > >? ? ? ? ? ? ? ? ?allowed in a node name (alivename@REDACTED) was thus > >? ? ? ? ? ? ? ? ?limited to 128 characters. These limits applied > both to > >? ? ? ? ? ? ? ? ?the own node name as well as node names of other > nodes. > >? ? ? ? ? ? ? ? ?Ordinary Erlang nodes limit the node name length > to 256 > >? ? ? ? ? ? ? ? ?characters, which meant that you could not > communicate > >? ? ? ? ? ? ? ? ?with certain Erlang nodes due to their node name > used. > > > >? ? ? ? ? ? ? ? ?erl_interface/ei now allow the total amount of > >? ? ? ? ? ? ? ? ?characters in a node name to be up to 256 characters. > >? ? ? ? ? ? ? ? ?These characters may be distributed between alive > name > >? ? ? ? ? ? ? ? ?and host name in whatever way needed. That is, the > >? ? ? ? ? ? ? ? ?maximum amount of characters in the alive name may be > >? ? ? ? ? ? ? ? ?254 and the maximum amount of characters in the host > >? ? ? ? ? ? ? ? ?name may be 254, but in total the node name must not > >? ? ? ? ? ? ? ? ?exceed 256 characters. > > > > > > > ?--------------------------------------------------------------------- > >? ?--- erts-10.3.5 > ----------------------------------------------------- > > > ?--------------------------------------------------------------------- > > > >? ?Note! The erts-10.3.5 application *cannot* be applied independently > >? ? ? ? ?of other applications on an arbitrary OTP 21 installation. > > > >? ? ? ? ?On a full OTP 21 installation, also the following runtime > >? ? ? ? ?dependencies have to be satisfied: > >? ? ? ? ?-- kernel-6.1 (first satisfied in OTP 21.1) > >? ? ? ? ?-- sasl-3.3 (first satisfied in OTP 21.2) > > > > > >? ?--- Fixed Bugs and Malfunctions --- > > > >? ? OTP-15793? ? Application(s): erts > >? ? ? ? ? ? ? ? ?Related Id(s): ERIERL-337, OTP-15709 > > > >? ? ? ? ? ? ? ? ?Fixed more bugs in process_info(reductions) > causing it > >? ? ? ? ? ? ? ? ?to sometimes behave non-monotonic. That is, a > >? ? ? ? ? ? ? ? ?subsequent call toward the same process could > return a > >? ? ? ? ? ? ? ? ?lower reduction value. > > > > > >? ?Full runtime dependencies of erts-10.3.5: kernel-6.1, sasl-3.3, > >? ?stdlib-3.5 > > > > > > > ?--------------------------------------------------------------------- > >? ?--- public_key-1.6.6 > ------------------------------------------------ > > > ?--------------------------------------------------------------------- > > > >? ?The public_key-1.6.6 application can be applied independently of > >? ?other applications on a full OTP 21 installation. > > > >? ?--- Improvements and New Features --- > > > >? ? OTP-15785? ? Application(s): eldap, public_key, ssl > >? ? ? ? ? ? ? ? ?Related Id(s): ERL-893, ERL-929, PR-2215 > > > >? ? ? ? ? ? ? ? ?Back port of bug fix ERL-893 from OTP-22 and document > >? ? ? ? ? ? ? ? ?enhancements that will solve dialyzer warnings for > >? ? ? ? ? ? ? ? ?users of the ssl application. > > > >? ? ? ? ? ? ? ? ?This change also affects public_key, eldap (and inet > >? ? ? ? ? ? ? ? ?doc). > > > > > >? ?Full runtime dependencies of public_key-1.6.6: asn1-3.0, > crypto-3.8, > >? ?erts-6.0, kernel-3.0, stdlib-3.5 > > > > > > > ?--------------------------------------------------------------------- > >? ?--- ssl-9.2.3 > ------------------------------------------------------- > > > ?--------------------------------------------------------------------- > > > >? ?The ssl-9.2.3 application can be applied independently of other > >? ?applications on a full OTP 21 installation. > > > >? ?--- Fixed Bugs and Malfunctions --- > > > >? ? OTP-15802? ? Application(s): ssl > >? ? ? ? ? ? ? ? ?Related Id(s): ERL-934 > > > >? ? ? ? ? ? ? ? ?Missing check of size of user_data_buffer made > internal > >? ? ? ? ? ? ? ? ?socket behave as an active socket instead of > active N. > >? ? ? ? ? ? ? ? ?This could cause memory problems. > > > > > >? ?--- Improvements and New Features --- > > > >? ? OTP-15785? ? Application(s): eldap, public_key, ssl > >? ? ? ? ? ? ? ? ?Related Id(s): ERL-893, ERL-929, PR-2215 > > > >? ? ? ? ? ? ? ? ?Back port of bug fix ERL-893 from OTP-22 and document > >? ? ? ? ? ? ? ? ?enhancements that will solve dialyzer warnings for > >? ? ? ? ? ? ? ? ?users of the ssl application. > > > >? ? ? ? ? ? ? ? ?This change also affects public_key, eldap (and inet > >? ? ? ? ? ? ? ? ?doc). > > > > > >? ?Full runtime dependencies of ssl-9.2.3: crypto-4.2, erts-10.0, > >? ?inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 > > > > > > > ?--------------------------------------------------------------------- > >? ?--- stdlib-3.8.2 > ---------------------------------------------------- > > > ?--------------------------------------------------------------------- > > > >? ?The stdlib-3.8.2 application can be applied independently of other > >? ?applications on a full OTP 21 installation. > > > >? ?--- Fixed Bugs and Malfunctions --- > > > >? ? OTP-15295? ? Application(s): stdlib > > > >? ? ? ? ? ? ? ? ?A bug in gen_statem has been fixed where the internal > >? ? ? ? ? ? ? ? ?timeout message could arrive as an info to the > callback > >? ? ? ? ? ? ? ? ?module during high load due to incorrect use of > >? ? ? ? ? ? ? ? ?asynchronous timer cancel. > > > > > >? ?Full runtime dependencies of stdlib-3.8.2: compiler-5.0, > crypto-3.3, > >? ?erts-10.0, kernel-6.0, sasl-3.0 > > > > > > > ?--------------------------------------------------------------------- > > > ?--------------------------------------------------------------------- > > > ?--------------------------------------------------------------------- > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > https://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin https://ninenines.eu From zxq9@REDACTED Wed May 8 14:40:43 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Wed, 08 May 2019 21:40:43 +0900 Subject: [erlang-questions] Maintenance for erlang.org 2019-05-10 16:00 -- 2019-05-11 14:00 CEST In-Reply-To: <20190507135345.GA9718@erix.ericsson.se> References: <20190507135345.GA9718@erix.ericsson.se> Message-ID: <14569722.tWndqerihb@takoyaki> On 2019?5?7???? 15?53?45? JST Raimo Niskanen wrote: > Hi all. > > erlang.org, i.e http download and mailing lists, documentation search, etc, > will be down for the first half of the upcoming weekend (Friday 16:00 > through Saturday 14:00 CEST) due to power maintenance work in the building. Thanks for the heads-up. As an FYI, I keep a docs mirror here: http://zxq9.com/erlang/docs/ -Craig From zxq9@REDACTED Wed May 8 15:34:17 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Wed, 08 May 2019 22:34:17 +0900 Subject: [erlang-questions] crypto:hmac/3 using hardware acceleration In-Reply-To: References: Message-ID: <7159017.ARYZdibLj6@takoyaki> On 2019?5?8???? 14?15?51? JST Ben Browitt wrote: > I've tested the speed with and without evp. evp is slower because Intel > cpus don't have hardware acceleration for sha. > So it's best to leave it without evp for now. Thanks. > openssl speed sha1 > openssl speed -evp sha1 I think it depends on how your openssl was built and which processor family you have. IIRC Intel has SHA1 hardware support, and AMD has SHA1 and SHA256 hardware instructions since RyZen. May also depend on if you are running virtualized and whether the hypervisor is exposing the instructions. In the base case I imagine it would "just work", but not if this is disabled in a vanilla Linux/BSD/whatever distribution binary, or if your system is set to a mode that restricts some instructions. -Craig From frank.muller.erl@REDACTED Wed May 8 15:56:55 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Wed, 8 May 2019 15:56:55 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8 Released In-Reply-To: References: <20190507085520.GA55005@erix.ericsson.se> <033034c1-01a9-ab31-a173-0d97e9c765f4@ninenines.eu> Message-ID: Excellent. When can we expect a new package to test? /Frank Yes. > > Ingela reacted quickly and did great work with a PR fixing the issue at > https://github.com/erlang/otp/pull/2224 > > Cheers, > > On 08/05/2019 13:19, Frank Muller wrote: > > So? Did we regress? > > > > /Frank > > > > Hello, > > > > Warning! Something's wrong with this release: > > > > https://bugs.erlang.org/browse/ERL-938 > > > > On 07/05/2019 10:55, Erlang/OTP wrote: > > > Patch Package: OTP 21.3.8 > > > Git Tag: OTP-21.3.8 > > > Date: 2019-05-07 > > > Trouble Report Id: OTP-14746, OTP-15295, OTP-15717, > OTP-15758, > > > OTP-15781, OTP-15785, OTP-15793, > OTP-15802 > > > Seq num: ERIERL-143, ERIERL-334, ERIERL-337, > > > ERIERL-342, ERIERL-356, ERL-893, > ERL-929, > > > ERL-934 > > > System: OTP > > > Release: 21 > > > Application: common_test-1.17.2, eldap-1.2.7, > > > erl_interface-3.11.3, erts-10.3.5, > > > public_key-1.6.6, ssl-9.2.3, > stdlib-3.8.2 > > > Predecessor: OTP 21.3.7 > > > > > > Check out the git tag OTP-21.3.8, 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. > > > > > > > > > --------------------------------------------------------------------- > > > --- POTENTIAL INCOMPATIBILITIES > > ------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > OTP-15717 Application(s): common_test > > > Related Id(s): ERIERL-334 > > > > > > The test result when a hook function fails is in > > > general the same as if the function that the hook > is > > > associated with fails. For example, if > > > post_init_per_testcase fails the result is that > the > > > test case is skipped, as is the case when > > > init_per_testcase fails.This, however, was > > earlier not > > > true for timetrap timeouts or other error > situations > > > where the process running the hook function was > > killed. > > > This is now corrected, so the error handling > > should be > > > the same no matter how the hook function fails. > > > > > > > > > > > > --------------------------------------------------------------------- > > > --- common_test-1.17.2 > > ---------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > The common_test-1.17.2 application can be applied independently > of > > > other applications on a full OTP 21 installation. > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > OTP-15717 Application(s): common_test > > > Related Id(s): ERIERL-334 > > > > > > *** POTENTIAL INCOMPATIBILITY *** > > > > > > The test result when a hook function fails is in > > > general the same as if the function that the hook > is > > > associated with fails. For example, if > > > post_init_per_testcase fails the result is that > the > > > test case is skipped, as is the case when > > > init_per_testcase fails.This, however, was > > earlier not > > > true for timetrap timeouts or other error > situations > > > where the process running the hook function was > > killed. > > > This is now corrected, so the error handling > > should be > > > the same no matter how the hook function fails. > > > > > > > > > OTP-15758 Application(s): common_test > > > Related Id(s): ERIERL-342 > > > > > > In some rare cases, when two common_test nodes > > used the > > > same log directory, a timing problem could occur > > which > > > caused common_test to crash because it's log > > cache file > > > was unexpectedly empty. This is now corrected. > > > > > > > > > --- Improvements and New Features --- > > > > > > OTP-14746 Application(s): common_test > > > Related Id(s): ERIERL-143 > > > > > > Two new common_test hook functions are introduced: > > > > > > post_groups/2, which is called after > Suite:groups/0 > > > post_all/3, which is called after Suite:all/0 > > > > > > These functions allow modifying the return values > > from > > > the groups/0 and all/0 functions, respectively. > > > > > > A new term, {testcase,TestCase,RepeatProperties} > > is now > > > also allowed in the return from all/0. This can > > be used > > > for repeating a single test case a specific > number of > > > times, or until it fails or succeeds once. > > > > > > > > > Full runtime dependencies of common_test-1.17.2: compiler-6.0, > > > crypto-3.6, debugger-4.1, erts-7.0, ftp-1.0.0, inets-6.0, > > kernel-4.0, > > > observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, > > ssh-4.0, > > > stdlib-3.5, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 > > > > > > > > > > > > --------------------------------------------------------------------- > > > --- eldap-1.2.7 > > ----------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > The eldap-1.2.7 application can be applied independently of > other > > > applications on a full OTP 21 installation. > > > > > > --- Improvements and New Features --- > > > > > > OTP-15785 Application(s): eldap, public_key, ssl > > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > > > Back port of bug fix ERL-893 from OTP-22 and > document > > > enhancements that will solve dialyzer warnings for > > > users of the ssl application. > > > > > > This change also affects public_key, eldap (and > inet > > > doc). > > > > > > > > > Full runtime dependencies of eldap-1.2.7: asn1-3.0, erts-6.0, > > > kernel-3.0, ssl-5.3.4, stdlib-2.0 > > > > > > > > > > > > --------------------------------------------------------------------- > > > --- erl_interface-3.11.3 > > -------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > The erl_interface-3.11.3 application can be applied > > independently of > > > other applications on a full OTP 21 installation. > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > OTP-15781 Application(s): erl_interface > > > Related Id(s): ERIERL-356 > > > > > > erl_interface/ei refused to use node names with an > > > alive name (the part of the node name preceding > the @ > > > sign) longer than 63 characters and a host name > > longer > > > than 64 characters. The total amount of characters > > > allowed in a node name (alivename@REDACTED) was > thus > > > limited to 128 characters. These limits applied > > both to > > > the own node name as well as node names of other > > nodes. > > > Ordinary Erlang nodes limit the node name length > > to 256 > > > characters, which meant that you could not > > communicate > > > with certain Erlang nodes due to their node name > > used. > > > > > > erl_interface/ei now allow the total amount of > > > characters in a node name to be up to 256 > characters. > > > These characters may be distributed between alive > > name > > > and host name in whatever way needed. That is, the > > > maximum amount of characters in the alive name > may be > > > 254 and the maximum amount of characters in the > host > > > name may be 254, but in total the node name must > not > > > exceed 256 characters. > > > > > > > > > > > > --------------------------------------------------------------------- > > > --- erts-10.3.5 > > ----------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > Note! The erts-10.3.5 application *cannot* be applied > independently > > > of other applications on an arbitrary OTP 21 installation. > > > > > > On a full OTP 21 installation, also the following runtime > > > dependencies have to be satisfied: > > > -- kernel-6.1 (first satisfied in OTP 21.1) > > > -- sasl-3.3 (first satisfied in OTP 21.2) > > > > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > OTP-15793 Application(s): erts > > > Related Id(s): ERIERL-337, OTP-15709 > > > > > > Fixed more bugs in process_info(reductions) > > causing it > > > to sometimes behave non-monotonic. That is, a > > > subsequent call toward the same process could > > return a > > > lower reduction value. > > > > > > > > > Full runtime dependencies of erts-10.3.5: kernel-6.1, sasl-3.3, > > > stdlib-3.5 > > > > > > > > > > > > --------------------------------------------------------------------- > > > --- public_key-1.6.6 > > ------------------------------------------------ > > > > > > --------------------------------------------------------------------- > > > > > > The public_key-1.6.6 application can be applied independently of > > > other applications on a full OTP 21 installation. > > > > > > --- Improvements and New Features --- > > > > > > OTP-15785 Application(s): eldap, public_key, ssl > > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > > > Back port of bug fix ERL-893 from OTP-22 and > document > > > enhancements that will solve dialyzer warnings for > > > users of the ssl application. > > > > > > This change also affects public_key, eldap (and > inet > > > doc). > > > > > > > > > Full runtime dependencies of public_key-1.6.6: asn1-3.0, > > crypto-3.8, > > > erts-6.0, kernel-3.0, stdlib-3.5 > > > > > > > > > > > > --------------------------------------------------------------------- > > > --- ssl-9.2.3 > > ------------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > The ssl-9.2.3 application can be applied independently of other > > > applications on a full OTP 21 installation. > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > OTP-15802 Application(s): ssl > > > Related Id(s): ERL-934 > > > > > > Missing check of size of user_data_buffer made > > internal > > > socket behave as an active socket instead of > > active N. > > > This could cause memory problems. > > > > > > > > > --- Improvements and New Features --- > > > > > > OTP-15785 Application(s): eldap, public_key, ssl > > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > > > Back port of bug fix ERL-893 from OTP-22 and > document > > > enhancements that will solve dialyzer warnings for > > > users of the ssl application. > > > > > > This change also affects public_key, eldap (and > inet > > > doc). > > > > > > > > > Full runtime dependencies of ssl-9.2.3: crypto-4.2, erts-10.0, > > > inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 > > > > > > > > > > > > --------------------------------------------------------------------- > > > --- stdlib-3.8.2 > > ---------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > The stdlib-3.8.2 application can be applied independently of > other > > > applications on a full OTP 21 installation. > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > OTP-15295 Application(s): stdlib > > > > > > A bug in gen_statem has been fixed where the > internal > > > timeout message could arrive as an info to the > > callback > > > module during high load due to incorrect use of > > > asynchronous timer cancel. > > > > > > > > > Full runtime dependencies of stdlib-3.8.2: compiler-5.0, > > crypto-3.3, > > > erts-10.0, kernel-6.0, sasl-3.0 > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > -- > > Lo?c Hoguin > > https://ninenines.eu > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > https://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Wed May 8 16:11:13 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 8 May 2019 16:11:13 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8 Released In-Reply-To: References: <20190507085520.GA55005@erix.ericsson.se> <033034c1-01a9-ab31-a173-0d97e9c765f4@ninenines.eu> Message-ID: <20190508141113.GA38095@erix.ericsson.se> On Wed, May 08, 2019 at 03:56:55PM +0200, Frank Muller wrote: > Excellent. When can we expect a new package to test? You can already now test the pull request. The more testing it gets the more confident we will be about releasing it. :-( / Raimo > > /Frank > > Yes. > > > > Ingela reacted quickly and did great work with a PR fixing the issue at > > https://github.com/erlang/otp/pull/2224 > > > > Cheers, > > > > On 08/05/2019 13:19, Frank Muller wrote: > > > So? Did we regress? > > > > > > /Frank > > > > > > Hello, > > > > > > Warning! Something's wrong with this release: > > > > > > https://bugs.erlang.org/browse/ERL-938 > > > > > > On 07/05/2019 10:55, Erlang/OTP wrote: > > > > Patch Package: OTP 21.3.8 > > > > Git Tag: OTP-21.3.8 > > > > Date: 2019-05-07 > > > > Trouble Report Id: OTP-14746, OTP-15295, OTP-15717, > > OTP-15758, > > > > OTP-15781, OTP-15785, OTP-15793, > > OTP-15802 > > > > Seq num: ERIERL-143, ERIERL-334, ERIERL-337, > > > > ERIERL-342, ERIERL-356, ERL-893, > > ERL-929, > > > > ERL-934 > > > > System: OTP > > > > Release: 21 > > > > Application: common_test-1.17.2, eldap-1.2.7, > > > > erl_interface-3.11.3, erts-10.3.5, > > > > public_key-1.6.6, ssl-9.2.3, > > stdlib-3.8.2 > > > > Predecessor: OTP 21.3.7 > > > > > > > > Check out the git tag OTP-21.3.8, 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. > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- POTENTIAL INCOMPATIBILITIES > > > ------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > OTP-15717 Application(s): common_test > > > > Related Id(s): ERIERL-334 > > > > > > > > The test result when a hook function fails is in > > > > general the same as if the function that the hook > > is > > > > associated with fails. For example, if > > > > post_init_per_testcase fails the result is that > > the > > > > test case is skipped, as is the case when > > > > init_per_testcase fails.This, however, was > > > earlier not > > > > true for timetrap timeouts or other error > > situations > > > > where the process running the hook function was > > > killed. > > > > This is now corrected, so the error handling > > > should be > > > > the same no matter how the hook function fails. > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- common_test-1.17.2 > > > ---------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > The common_test-1.17.2 application can be applied independently > > of > > > > other applications on a full OTP 21 installation. > > > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > > > OTP-15717 Application(s): common_test > > > > Related Id(s): ERIERL-334 > > > > > > > > *** POTENTIAL INCOMPATIBILITY *** > > > > > > > > The test result when a hook function fails is in > > > > general the same as if the function that the hook > > is > > > > associated with fails. For example, if > > > > post_init_per_testcase fails the result is that > > the > > > > test case is skipped, as is the case when > > > > init_per_testcase fails.This, however, was > > > earlier not > > > > true for timetrap timeouts or other error > > situations > > > > where the process running the hook function was > > > killed. > > > > This is now corrected, so the error handling > > > should be > > > > the same no matter how the hook function fails. > > > > > > > > > > > > OTP-15758 Application(s): common_test > > > > Related Id(s): ERIERL-342 > > > > > > > > In some rare cases, when two common_test nodes > > > used the > > > > same log directory, a timing problem could occur > > > which > > > > caused common_test to crash because it's log > > > cache file > > > > was unexpectedly empty. This is now corrected. > > > > > > > > > > > > --- Improvements and New Features --- > > > > > > > > OTP-14746 Application(s): common_test > > > > Related Id(s): ERIERL-143 > > > > > > > > Two new common_test hook functions are introduced: > > > > > > > > post_groups/2, which is called after > > Suite:groups/0 > > > > post_all/3, which is called after Suite:all/0 > > > > > > > > These functions allow modifying the return values > > > from > > > > the groups/0 and all/0 functions, respectively. > > > > > > > > A new term, {testcase,TestCase,RepeatProperties} > > > is now > > > > also allowed in the return from all/0. This can > > > be used > > > > for repeating a single test case a specific > > number of > > > > times, or until it fails or succeeds once. > > > > > > > > > > > > Full runtime dependencies of common_test-1.17.2: compiler-6.0, > > > > crypto-3.6, debugger-4.1, erts-7.0, ftp-1.0.0, inets-6.0, > > > kernel-4.0, > > > > observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, > > > ssh-4.0, > > > > stdlib-3.5, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- eldap-1.2.7 > > > ----------------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > The eldap-1.2.7 application can be applied independently of > > other > > > > applications on a full OTP 21 installation. > > > > > > > > --- Improvements and New Features --- > > > > > > > > OTP-15785 Application(s): eldap, public_key, ssl > > > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > > > > > Back port of bug fix ERL-893 from OTP-22 and > > document > > > > enhancements that will solve dialyzer warnings for > > > > users of the ssl application. > > > > > > > > This change also affects public_key, eldap (and > > inet > > > > doc). > > > > > > > > > > > > Full runtime dependencies of eldap-1.2.7: asn1-3.0, erts-6.0, > > > > kernel-3.0, ssl-5.3.4, stdlib-2.0 > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- erl_interface-3.11.3 > > > -------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > The erl_interface-3.11.3 application can be applied > > > independently of > > > > other applications on a full OTP 21 installation. > > > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > > > OTP-15781 Application(s): erl_interface > > > > Related Id(s): ERIERL-356 > > > > > > > > erl_interface/ei refused to use node names with an > > > > alive name (the part of the node name preceding > > the @ > > > > sign) longer than 63 characters and a host name > > > longer > > > > than 64 characters. The total amount of characters > > > > allowed in a node name (alivename@REDACTED) was > > thus > > > > limited to 128 characters. These limits applied > > > both to > > > > the own node name as well as node names of other > > > nodes. > > > > Ordinary Erlang nodes limit the node name length > > > to 256 > > > > characters, which meant that you could not > > > communicate > > > > with certain Erlang nodes due to their node name > > > used. > > > > > > > > erl_interface/ei now allow the total amount of > > > > characters in a node name to be up to 256 > > characters. > > > > These characters may be distributed between alive > > > name > > > > and host name in whatever way needed. That is, the > > > > maximum amount of characters in the alive name > > may be > > > > 254 and the maximum amount of characters in the > > host > > > > name may be 254, but in total the node name must > > not > > > > exceed 256 characters. > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- erts-10.3.5 > > > ----------------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > Note! The erts-10.3.5 application *cannot* be applied > > independently > > > > of other applications on an arbitrary OTP 21 installation. > > > > > > > > On a full OTP 21 installation, also the following runtime > > > > dependencies have to be satisfied: > > > > -- kernel-6.1 (first satisfied in OTP 21.1) > > > > -- sasl-3.3 (first satisfied in OTP 21.2) > > > > > > > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > > > OTP-15793 Application(s): erts > > > > Related Id(s): ERIERL-337, OTP-15709 > > > > > > > > Fixed more bugs in process_info(reductions) > > > causing it > > > > to sometimes behave non-monotonic. That is, a > > > > subsequent call toward the same process could > > > return a > > > > lower reduction value. > > > > > > > > > > > > Full runtime dependencies of erts-10.3.5: kernel-6.1, sasl-3.3, > > > > stdlib-3.5 > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- public_key-1.6.6 > > > ------------------------------------------------ > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > The public_key-1.6.6 application can be applied independently of > > > > other applications on a full OTP 21 installation. > > > > > > > > --- Improvements and New Features --- > > > > > > > > OTP-15785 Application(s): eldap, public_key, ssl > > > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > > > > > Back port of bug fix ERL-893 from OTP-22 and > > document > > > > enhancements that will solve dialyzer warnings for > > > > users of the ssl application. > > > > > > > > This change also affects public_key, eldap (and > > inet > > > > doc). > > > > > > > > > > > > Full runtime dependencies of public_key-1.6.6: asn1-3.0, > > > crypto-3.8, > > > > erts-6.0, kernel-3.0, stdlib-3.5 > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- ssl-9.2.3 > > > ------------------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > The ssl-9.2.3 application can be applied independently of other > > > > applications on a full OTP 21 installation. > > > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > > > OTP-15802 Application(s): ssl > > > > Related Id(s): ERL-934 > > > > > > > > Missing check of size of user_data_buffer made > > > internal > > > > socket behave as an active socket instead of > > > active N. > > > > This could cause memory problems. > > > > > > > > > > > > --- Improvements and New Features --- > > > > > > > > OTP-15785 Application(s): eldap, public_key, ssl > > > > Related Id(s): ERL-893, ERL-929, PR-2215 > > > > > > > > Back port of bug fix ERL-893 from OTP-22 and > > document > > > > enhancements that will solve dialyzer warnings for > > > > users of the ssl application. > > > > > > > > This change also affects public_key, eldap (and > > inet > > > > doc). > > > > > > > > > > > > Full runtime dependencies of ssl-9.2.3: crypto-4.2, erts-10.0, > > > > inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > --- stdlib-3.8.2 > > > ---------------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > The stdlib-3.8.2 application can be applied independently of > > other > > > > applications on a full OTP 21 installation. > > > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > > > OTP-15295 Application(s): stdlib > > > > > > > > A bug in gen_statem has been fixed where the > > internal > > > > timeout message could arrive as an info to the > > > callback > > > > module during high load due to incorrect use of > > > > asynchronous timer cancel. > > > > > > > > > > > > Full runtime dependencies of stdlib-3.8.2: compiler-5.0, > > > crypto-3.3, > > > > erts-10.0, kernel-6.0, sasl-3.0 > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-questions@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > -- > > > Lo?c Hoguin > > > https://ninenines.eu > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > -- > > Lo?c Hoguin > > https://ninenines.eu > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From zxq9@REDACTED Wed May 8 16:18:17 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Wed, 08 May 2019 23:18:17 +0900 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: References: <1557178848.685810263@apps.rackspace.com> <20190507221734.3c188749@raspy> Message-ID: <1926165.L5vG8RSdrt@takoyaki> On 2019?5?8???? 10?53?25? JST Richard O'Keefe wrote: > For what it's worth, in Unicode, Line Separator and Paragraph > Separator are the recommended characters, with CR, LF, CR+LF, > and of arguably NEL (U+0085) being "legacy". > > Again for what it's worth, Unicode defines an algorithm for > breaking text into word( token)s. I don't really mind the term "lexeme", but I've wondered why the existing tokens/2 function wasn't simply updated to work the way lexemes/2 works. If we needed a new function, it seems the name "tokenize/2" might have been an easier mental adjustment. But anyway, naming things is hard and... meh. For me the unicode enhancements are a big enough deal that I could *almost* care less what they are called. That said, who isn't going to open a new language's string lib and expect to find things called "split" "tokenize"/"tokens", "clean", "right", "left", "pad", etc.? -Craig From kenneth@REDACTED Wed May 8 16:46:16 2019 From: kenneth@REDACTED (Kenneth Lundin) Date: Wed, 8 May 2019 16:46:16 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8 Released In-Reply-To: <20190507085520.GA55005@erix.ericsson.se> References: <20190507085520.GA55005@erix.ericsson.se> Message-ID: The SSL part of this patch is not good and introduces problems. We are working on a new patch which will solve the problem. There is already a pull request with a proposed new solution which you can test https://github.com/erlang/otp/pull/2224 Meanwhile you should not apply this patch (OTP-21.3.8) if you are dependent on the SSL application. /Regards Kenneth, Erlang/OTP Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Wed May 8 17:47:11 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Wed, 8 May 2019 22:47:11 +0700 Subject: [erlang-questions] Profiling code in Erlang In-Reply-To: References: Message-ID: Yes i need this also, please help Pada tanggal Min, 5 Mei 2019 03.00, jacques yakoub < jacques.yakoub@REDACTED> menulis: > Hello, > > I explored the profiling section of the documentation ( > http://erlang.org/doc/efficiency_guide/profiling.html ) and I would like > to know how can I get memory usage stats ( for example the module "x" takes > *** mb of ram, etc ) > > Thanks for the help > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Wed May 8 17:57:30 2019 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 8 May 2019 17:57:30 +0200 Subject: [erlang-questions] Profiling code in Erlang In-Reply-To: References: Message-ID: Hello! What exactly is it that you want to know? How much memory a module takes can be roughly found out by looking at the return value of erlang:memory/0 before and after the module is loaded. Though I suspect that this is not what you want to know, as that is not very helpful information. Lukas On Wed, May 8, 2019 at 5:48 PM I Gusti Ngurah Oka Prinarjaya < okaprinarjaya@REDACTED> wrote: > Yes i need this also, please help > > > Pada tanggal Min, 5 Mei 2019 03.00, jacques yakoub < > jacques.yakoub@REDACTED> menulis: > >> Hello, >> >> I explored the profiling section of the documentation ( >> http://erlang.org/doc/efficiency_guide/profiling.html ) and I would like >> to know how can I get memory usage stats ( for example the module "x" takes >> *** mb of ram, etc ) >> >> Thanks for the help >> _______________________________________________ >> 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 empro2@REDACTED Thu May 9 12:52:11 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Thu, 9 May 2019 12:52:11 +0200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <1926165.L5vG8RSdrt@takoyaki> References: <1557178848.685810263@apps.rackspace.com> <20190507221734.3c188749@raspy> <1926165.L5vG8RSdrt@takoyaki> Message-ID: <20190509125211.1f4e0a00@raspy> On Wed, 08 May 2019 23:18:17 +0900 zxq9@REDACTED wrote: > On 2019?5?8???? 10?53?25? JST Richard O'Keefe > wrote: > > Again for what it's worth, Unicode defines an algorithm > > for breaking text into word( token)s. > > I don't really mind the term "lexeme", What if someone wants to break their "text" into chippy-choppy-parts and neither words, nor tokens, nor lexemes? and even if their parts could be called one of these in some context they do not want to know? > If we needed a new function, it seems the name > "tokenize/2" might have been an easier mental adjustment. Oh, the dark side is not stronger, but easier, more seductive ... In a functional language I want names describe the result not the action producing that result. Imperative send() and fwrite() are fine because they are no functions (mapping args to result) but mere procedures that happen to return something more or less useful. No wonder that send() is Prolog's exclamation mark: no backtracking across a message sent. > But anyway, naming things is hard Actually it is *much* too easy, but finding *good* names, good in all, or at least the most important contexts ... But I am sure that is what you mean. > unicode enhancements are a big enough deal that I could > *almost* care less what they are called. As I have buried in my much ignored "Help" posting: The complexity saved in the small, unimportant (each on its own) but numerous details frees capacity for complexity on the higher levels. So "almost" could be too little ... > That said, who isn't going to open a new language's > string lib and expect to find things called "split" *I* do not want other languages in Erlang, lest someone says "Hej, look at this great PHP lib ...". Of course, Erlang cannot be a completely new kind of wheel, but I wonder whether it is running faster than it can without stumbling, recently, unnecessarily(?) trying to catch up to something ... ~Michael -- Reasonable is that which cannot be criticised reasonably. From raoknz@REDACTED Thu May 9 13:34:00 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Thu, 9 May 2019 23:34:00 +1200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <20190508123616.625b7d32@raspy> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> <7477D767-9DDC-4036-BDAA-662D3E3B6A45@writersglen.com> <20190508123616.625b7d32@raspy> Message-ID: Do not eat a lot of Chinese Gooseberries (the fruit whose name was changed by the company Turners and Growers for marketing reasons, back before Ping-Pong Diplomacy) unless you want to lose weight by running frequently to the small room. Actinidia deliciosa wants its fruit eaten but not fully digested, for the sake of the seeds. (https://nzhistory.govt.nz/the-chinese-gooseberry-becomes-the-kiwifruit explains the name change. I still use the old name.) To be honest, the first time I saw the function name 'tokens', I expected something returning *Erlang* tokens, then when I saw 'lexemes', I said to myself "NOW they have a function that does what I thought tokens did". Wrong again. Here's an apropos example from the ANSI Smalltalk standard. aString subStrings: separators The first thing to note is that this actually violates Smalltalk naming conventions: internal capitals are only to be used at *word* boundaries, not *morpheme* boundaries. And 'sub-' as used here is a prefix, not a word. Some Smalltalk implementations have changed it to 'substrings'. One has renamed it to aString asCollectionOfSubstringsSeparatedByAnyOf: separators The second thing to note is that the description given for it is hopelessly vague. If anyone thinks that the Erlang library documentation needs improving -- as I do -- at least it isn't an actual *standard*! This operation does pretty much the same thing as string:tokens/2, but you would never guess it from the text in the standard. Oh, did I mention that the Erlang documentation is free but the ANSI Smalltalk standard is not? The Erlang documentation is definitely value for money. One of these days I must really ask to be allowed to edit some of the Erlang documentation, but I'm afraid that if I do people will discover that I'm better at criticising than writing. On Wed, 8 May 2019 at 22:36, wrote: > On Wed, 8 May 2019 00:27:41 -0400 > "Lloyd R. Prentice" wrote: > > > Richard, you?re a star in the Erlang firmament. > > Not at all limited to Erlang, not even to all the > languages he has ever mentioned; so it is at least the > programming languages firmament ... oh, and the unicode > firmament, it appears ... > > I sometimes wonder whether I should eat more kiwis, sorry! > kiwi fruit, of course ... then again ... ;-) > > ~Michael > > -- > > If a *bank* in need of money is systematically important, > then that system is not important. > > > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empro2@REDACTED Thu May 9 14:28:03 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Thu, 9 May 2019 14:28:03 +0200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> Message-ID: <20190509142803.0ce94ed5@raspy> On Wed, 8 May 2019 10:53:25 +1200 "Richard O'Keefe" wrote: > For what it's worth, in Unicode, Line Separator and > Paragraph Separator are the recommended characters, with > CR, LF, CR+LF, and of arguably NEL (U+0085) being > "legacy". Does that matter in a function not called `uc_lines` or such? > Again for what it's worth, Unicode defines an algorithm > for breaking text into word( token)s. "a=1&b=2&c=me+tomorrow" "b=2" is no word, would UC call that a "token"? and if so, would or should that matter to the user? I would say that UC *is* an algorithm and no mere encoding anymore. My impression is it has taken some wrong turns and is now rolling down some strange hill driven by its mere weight. It seems to push any available metadata onto each character and then disunifies them in a way that makes every single character reflect half of its context without ever asking: Who is ever going to enter all these correctly? even if the glyphs for those in a font happen to be distinct. In this context I often picture a Norwegian professor at the blackboard writing in Norsk (?, ?) about empty sets (?) and average (?) diameters (?) .... And then again it does not, as 'average' and 'diameter' are the same ... And combining stuff requiring "canonisation"(?) and allowing funny things like "???" and utter rubbish "???" ... And please tell the Maaori to replace "wh" with "f", "ng" with "g" and, as some already do, macrons with double vocals. ;-) Simplify, simplify, simplify; things gets complex more than enough all on their own ... no, wait, things have already got ... ~Michael -- That which was said, is not that which was spoken, but that which was understood; and none of these comes necessarily close to that which was meant. From raoknz@REDACTED Thu May 9 14:48:05 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Fri, 10 May 2019 00:48:05 +1200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <1926165.L5vG8RSdrt@takoyaki> References: <1557178848.685810263@apps.rackspace.com> <20190507221734.3c188749@raspy> <1926165.L5vG8RSdrt@takoyaki> Message-ID: Who isn't going to expect 'split' 'tokenize'/'tokens' 'clean' 'right' 'left' 'pad'? A Ruby programmer will recognise 'split' from that list but nothing else. An SML programmer will recognise 'tokens' but nothing else. A Haskell programmer will wonder whether left/right correspond to justifyLeft/ justifyRight and if so, which way around. 'split' might be OK, if only I knew' what you expect it to do. An F# or C# programmer will wonder whether left/right correspond to padLeft/ padRight and if so, which way around. As for 'split', which of the 10 methods by that name did you have in mind? A PL/I programmer will expect 'left' and 'right' to correspond to LEFT and RIGHT (or possibly the other way around, depending on whether the focus is where the *string* goes or where the *padding* goes). The others will be a complete mystery. A Simula programmer won't have a clue what any of these are and will be disappointed by strings that don't have a movable cursor. An OCaml programmer will hope that 'split' is related to 'split_on_char' but will not have any idea what the other functions are. A Python programmer may be surprised that 'split' is actually 'tokens'. And so it goes. What *does* 'clean' do? On Thu, 9 May 2019 at 02:18, wrote: > On 2019?5?8???? 10?53?25? JST Richard O'Keefe wrote: > > For what it's worth, in Unicode, Line Separator and Paragraph > > Separator are the recommended characters, with CR, LF, CR+LF, > > and of arguably NEL (U+0085) being "legacy". > > > > Again for what it's worth, Unicode defines an algorithm for > > breaking text into word( token)s. > > I don't really mind the term "lexeme", but I've wondered why the > existing tokens/2 function wasn't simply updated to work the way > lexemes/2 works. > > If we needed a new function, it seems the name "tokenize/2" might > have been an easier mental adjustment. > > But anyway, naming things is hard and... meh. For me the unicode > enhancements are a big enough deal that I could *almost* care less > what they are called. > > That said, who isn't going to open a new language's string lib and > expect to find things called "split" "tokenize"/"tokens", "clean", > "right", "left", "pad", etc.? > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empro2@REDACTED Thu May 9 15:31:10 2019 From: empro2@REDACTED (empro2@REDACTED) Date: Thu, 9 May 2019 15:31:10 +0200 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> <7477D767-9DDC-4036-BDAA-662D3E3B6A45@writersglen.com> <20190508123616.625b7d32@raspy> Message-ID: <20190509153110.08bf6a05@raspy> On Thu, 9 May 2019 23:34:00 +1200 "Richard O'Keefe" wrote: > To be honest, the first time I saw the function name > 'tokens', I expected something returning *Erlang* tokens That is what I meant by "foisting meaning onto substrings". > aString subStrings: separators > > The first thing to note is that this actually violates > Smalltalk naming conventions: First thing I noted was: they also allow more than one separator at once. Against a performance argument I weigh simplicity, all the more so if separating substrings would allow interdependencies (a simple hint at list order might suffice to prevent such). > 'substrings'. One has renamed it to aString > asCollectionOfSubstringsSeparatedByAnyOf: separators Reminds me of my contextfreely-descriptive names of 20 years ago ... > One of these days I must really ask to be allowed to edit > some of the Erlang documentation, but I'm afraid that if > I do people will discover that I'm better at criticising > than writing. That is why I would like to bring in the host of fools like myself, who do not yet "know what is meant" but have workforce in numbers. We have to read it anyway and only at this point we remember what is "useful" and the questions that come up; but I think it unlikely people will go dig up source and push pull forget what they were doing. I cannot work that way (possibly lack of git routine), and I cannot stand to ignore all those opportunities to improve something good. So I cannot get on with my rubbish code, hit the git-index-stage-cached-confusion, which starts all this over again, and ... forget what I wanted to do ... :-) ~Michael -- Satire is the opium of the intellectual. From otp@REDACTED Thu May 9 18:35:11 2019 From: otp@REDACTED (Erlang/OTP) Date: Thu, 9 May 2019 18:35:11 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.7.1 Released Message-ID: <20190509163510.GA37452@erix.ericsson.se> Patch Package: OTP 21.3.7.1 Git Tag: OTP-21.3.7.1 Date: 2019-05-09 Trouble Report Id: OTP-15781 Seq num: ERIERL-356 System: OTP Release: 21 Application: erl_interface-3.11.2.1 Predecessor: OTP 21.3.7 Check out the git tag OTP-21.3.7.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. --------------------------------------------------------------------- --- erl_interface-3.11.2.1 ------------------------------------------ --------------------------------------------------------------------- The erl_interface-3.11.2.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15781 Application(s): erl_interface Related Id(s): ERIERL-356 erl_interface/ei refused to use node names with an alive name (the part of the node name preceding the @ sign) longer than 63 characters and a host name longer than 64 characters. The total amount of characters allowed in a node name (alivename@REDACTED) was thus limited to 128 characters. These limits applied both to the own node name as well as node names of other nodes. Ordinary Erlang nodes limit the node name length to 256 characters, which meant that you could not communicate with certain Erlang nodes due to their node name used. erl_interface/ei now allow the total amount of characters in a node name to be up to 256 characters. These characters may be distributed between alive name and host name in whatever way needed. That is, the maximum amount of characters in the alive name may be 254 and the maximum amount of characters in the host name may be 254, but in total the node name must not exceed 256 characters. --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From lloyd@REDACTED Thu May 9 19:06:30 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Thu, 9 May 2019 13:06:30 -0400 Subject: [erlang-questions] string:lexeme/s2 - an old man's rant In-Reply-To: <20190509153110.08bf6a05@raspy> References: <1557178848.685810263@apps.rackspace.com> <20190507075601.GI5426@carfax.org.uk> <8B8629A1-8234-4ADC-91EC-1794C8B41159@writersglen.com> <20190507221734.3c188749@raspy> <1D911775-1C41-4484-9923-FDE0ADA49E2A@writersglen.com> <7477D767-9DDC-4036-BDAA-662D3E3B6A45@writersglen.com> <20190508123616.625b7d32@raspy> <20190509153110.08bf6a05@raspy> Message-ID: <2249EA52-030E-4D02-AE46-68B200111332@writersglen.com> Hi All, In the grumpy moment when I launched this thread I never expected so many interesting insights and comments. Now I want to step back and convey boundless gratitude to all who have worked so hard to develop and document Erlang. Thank you. It?s clear that Erlang, the language, and official documentation are living entities? subject to changes that risk breaking legacy code and programmer expectations and mind set. As I understand it, string processing was not so important in telecom applications. But today we see Erlang in chat and web applications where processing natural language is fundamental. So pragmatic questions: ? Is the string library sufficiently up to the task in these new domains? ? Can it be improved? ? If so, how? ? Is there an official process through which these questions can be answered and targeted improvements brought to pass? All the best, Lloyd Sent from my iPad > On May 9, 2019, at 9:31 AM, wrote: > > On Thu, 9 May 2019 23:34:00 +1200 > "Richard O'Keefe" wrote: > >> To be honest, the first time I saw the function name >> 'tokens', I expected something returning *Erlang* tokens > > That is what I meant by "foisting meaning onto substrings". > > >> aString subStrings: separators >> >> The first thing to note is that this actually violates >> Smalltalk naming conventions: > > First thing I noted was: they also allow more than one > separator at once. Against a performance argument I weigh > simplicity, all the more so if separating substrings > would allow interdependencies (a simple hint at list > order might suffice to prevent such). > > >> 'substrings'. One has renamed it to aString >> asCollectionOfSubstringsSeparatedByAnyOf: separators > > Reminds me of my contextfreely-descriptive names of 20 > years ago ... > > >> One of these days I must really ask to be allowed to edit >> some of the Erlang documentation, but I'm afraid that if >> I do people will discover that I'm better at criticising >> than writing. > > That is why I would like to bring in the host of fools like > myself, who do not yet "know what is meant" but have > workforce in numbers. We have to read it anyway and only at > this point we remember what is "useful" and the questions > that come up; but I think it unlikely people will go dig up > source and push pull forget what they were doing. I cannot > work that way (possibly lack of git routine), and I cannot > stand to ignore all those opportunities to improve > something good. So I cannot get on with my rubbish code, > hit the git-index-stage-cached-confusion, which starts > all this over again, and ... forget what I wanted to > do ... :-) > > ~Michael > > -- > > Satire is the opium of the intellectual. > > > > > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From areege.alzubaidi@REDACTED Thu May 9 19:33:17 2019 From: areege.alzubaidi@REDACTED (Areege Al Zubaidi) Date: Thu, 9 May 2019 18:33:17 +0100 Subject: [erlang-questions] Last chance! one week to Code BEAM STO 19! Message-ID: Hi all, It?s almost Code BEAM STO time! Code BEAM STO is back next week with the biggest Erlang and Elixir lineup in Europe! If you haven?t secured your conference, training, or certification tickets yet, act quick as ticket prices rise at midnight tonight! Code BEAM STO offers training courses and certification , as well as a host of talks from leaders and innovators in the community, including: - Jose Valim - Madeleine Malmsten - Boyd Multerer - Peter van Roy - Ingela Anderton Andin - Ayanda Dube - Viktoria Fordos - Kenji Rikitake - Anayeli Malvaez - Thomas Arts - Stavros Aronis - Manuel Rubio - ? and more! Learn more about the conference, and the 2019 speakers: https://codesync.global/conferences/code-beam-sto-2019/#speakers What: Code BEAM STO 2019 When: 16-17 May 2019 Where: M?nchenbryggeriet, Stockholm Sweden How to attend: - Attend the conference Secure a standard rate ticket to the conference before midnight tonight, after which you can buy a more expensive ticket at the last minute rate. You can find out more and register here . - Student tickets Code BEAM STO offers a 50% discount to students. To learn more, email info@REDACTED from your academic email address to get a unique discount code. - Training There are very limited places remaining on advanced Erlang and OTP training with Robert Virding , or Elixir training with Martin Gausby . Get one of the last places now before they sell out. Bonus: get 10% off of your conference ticket when you buy a training place, just select the bundle at checkout. - Group discounts Bring the whole team along! We offer group discounts, to learn more contact the team at info@REDACTED If you have any further questions, please don?t hesitate to let me know, I hope to see you in Stockholm, the home of Erlang! Areege -- *Areege Al Zubaidi* *Conferences Marketing Executive* T: +44 (0) 2076550332 W: www.codesync.global A: Erlang Solutions Ltd, The Loom,14 Gower's Walk, London, E1 8PY *Code Sync & Erlang Solutions Conferences* Code BEAM STO - Stockholm - 16-17 May 2019 Code Elixir LDN - London - 18 July 2019 Code BEAM Lite BD - Budapest - 20 September 2019 RabbitMQ Summit - London - 5 November 2019 Code Mesh LDN - London - 7-8 November 2019 Code BEAM Lite AMS - Amsterdam - 29 November 2019 Lambda Days - Krak?w - 13-14 February 2020 *Erlang Solutions and Code Sync care about your data and privacy; please find all details about the basis for communicating with you and the way we process your data in our Privacy Policy . You can update your email preferences or opt-out from receiving marketing emails here .* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Fri May 10 04:31:47 2019 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 10 May 2019 10:31:47 +0800 Subject: [erlang-questions] Should uri_string:dissect_query/1 be able to parse this? Message-ID: uri_string is a solid module and great addition. I like using it whenever possible. But, > uri_string:dissect_query("b=12&a"). {error,missing_value,<<>>} whenever there is a key without a trailing =. Does it make more sense to be able to parse these query strings? From marc@REDACTED Fri May 10 09:50:23 2019 From: marc@REDACTED (Marc Worrell) Date: Fri, 10 May 2019 09:50:23 +0200 Subject: [erlang-questions] Should uri_string:dissect_query/1 be able to parse this? In-Reply-To: References: Message-ID: A query argument without a ?=? is something you see quite often. So in my opinion the uri_string module should be able to handle it. - Marc > On 10 May 2019, at 04:31, Leo Liu wrote: > > uri_string is a solid module and great addition. I like using it > whenever possible. But, > >> uri_string:dissect_query("b=12&a"). > {error,missing_value,<<>>} > > whenever there is a key without a trailing =. > > Does it make more sense to be able to parse these query strings? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Fri May 10 09:59:37 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Fri, 10 May 2019 09:59:37 +0200 Subject: [erlang-questions] Should uri_string:dissect_query/1 be able to parse this? In-Reply-To: References: Message-ID: <9f8fe95e-7f5e-e1e4-de4e-31c7c9742d00@ninenines.eu> Not just common, it's not an error. The parsing code must be https://url.spec.whatwg.org/#urlencoded-parsing to be correct. On 10/05/2019 09:50, Marc Worrell wrote: > A query argument without a ?=? is something you see quite often. > So in my opinion the uri_string module should be able to handle it. > > - Marc > > >> On 10 May 2019, at 04:31, Leo Liu wrote: >> >> uri_string is a solid module and great addition. I like using it >> whenever possible. But, >> >>> uri_string:dissect_query("b=12&a"). >> {error,missing_value,<<>>} >> >> whenever there is a key without a trailing =. >> >> Does it make more sense to be able to parse these query strings? >> >> _______________________________________________ >> 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 https://ninenines.eu From boyofmonk@REDACTED Fri May 10 11:53:25 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Fri, 10 May 2019 17:53:25 +0800 Subject: [erlang-questions] Warning: the call to node/0 has no effect Message-ID: Hi When compile the code , I got a message: ``` src/http_qmonitor.erl:58: Warning: the call to node/0 has no effect ``` the code is ``` N = length([node()|nodes()]), ``` I can't understand what is it -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Fri May 10 13:19:49 2019 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 10 May 2019 13:19:49 +0200 Subject: [erlang-questions] Warning: the call to node/0 has no effect In-Reply-To: References: Message-ID: On Fri, May 10, 2019 at 12:00 PM Monk Boy wrote: > > Hi > > When compile the code , I got a message: > > ``` > src/http_qmonitor.erl:58: Warning: the call to node/0 has no effect > ``` > > the code is > > ``` > N = length([node()|nodes()]), > ``` > Internally, the compiler does a series rewrites. First we have: V1 = node(), V2 = nodes(), N = length([V1|V2]) Then the compiler rewrites the code like so: V1 = node(), V2 = nodes(), N = length(V2) + 1 since the length of the list does not depend on the value value of V1. It then notices that V1 is no longer used, issues a warning and rewrites the code like so: V2 = nodes(), N = length(V2) + 1 /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From boyofmonk@REDACTED Fri May 10 13:23:16 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Fri, 10 May 2019 19:23:16 +0800 Subject: [erlang-questions] Warning: the call to node/0 has no effect In-Reply-To: References: Message-ID: thanks,I got it!!! On Fri, May 10, 2019 at 7:20 PM Bj?rn Gustavsson wrote: > On Fri, May 10, 2019 at 12:00 PM Monk Boy wrote: > > > > Hi > > > > When compile the code , I got a message: > > > > ``` > > src/http_qmonitor.erl:58: Warning: the call to node/0 has no effect > > ``` > > > > the code is > > > > ``` > > N = length([node()|nodes()]), > > ``` > > > > Internally, the compiler does a series rewrites. First we have: > > V1 = node(), > V2 = nodes(), > N = length([V1|V2]) > > Then the compiler rewrites the code like so: > > V1 = node(), > V2 = nodes(), > N = length(V2) + 1 > > since the length of the list does not depend on the value value of V1. > > It then notices that V1 is no longer used, issues a warning and > rewrites the code like so: > > V2 = nodes(), > N = length(V2) + 1 > > /Bj?rn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.welham@REDACTED Fri May 10 12:52:02 2019 From: stuart.welham@REDACTED (Stuart Welham) Date: Fri, 10 May 2019 11:52:02 +0100 Subject: [erlang-questions] Warning: the call to node/0 has no effect In-Reply-To: References: Message-ID: Hi I'm not certain but I would guess because you are not actually using the result of node() here and this creates a new list where it's not needed. How about refactoring this to be N = length(nodes()) + 1 -Stuart On Fri, 10 May 2019 at 11:00, Monk Boy wrote: > Hi > > When compile the code , I got a message: > > ``` > src/http_qmonitor.erl:58: Warning: the call to node/0 has no effect > ``` > > the code is > > ``` > N = length([node()|nodes()]), > ``` > > I can't understand what is it > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vfordos@REDACTED Fri May 10 14:33:45 2019 From: vfordos@REDACTED (Viktoria Fordos (vfordos)) Date: Fri, 10 May 2019 12:33:45 +0000 Subject: [erlang-questions] CfP: Erlang Workshop 2019 [Deadline extended] Message-ID: <41D07C74-6A7C-4A2F-804B-4DFFC76866F4@cisco.com> Hi everyone, We have decided to extend the paper submission deadline for the 18th ACM SIGPLAN Erlang Workshop. New final dates are as follows, there will not be any further extensions Submissions due: Sun, May 19, 2019 [extended] Author notification: Fri June 14, 2019 [extended] Final submission for the publisher: Sun June 30, 2019 [unchanged] Workshop date: Sun August 18, 2019 [unchanged] Apologies for any duplicates you may receive. Technical, practice, and application papers related to Erlang, BEAM, Elixir, Scala/Akka, CloudHaskell, Lisp Flavoured Erlang, OCaml, and functional programming are welcome and encouraged. LAST CALL FOR PAPERS Eighteenth ACM SIGPLAN Erlang Workshop https://icfp19.sigplan.org/home/erlang-2019 Berlin, Germany, 18 August 2019 Satellite event of the 24th ACM SIGPLAN International Conference on Functional Programming (ICFP 2019) 18 - 23 August, 2019 The Erlang Workshop aims to bring together the open source, academic, and industrial communities of Erlang, to discuss technologies and languages related to Erlang. The Erlang model of concurrent programming has been widely emulated, for example by Akka in Scala, and even new programming languages were designed atop of the Erlang VM, such as Elixir. Therefore we would like to broaden the scope of the workshop to include systems like those mentioned above. The workshop will enable participants to familiarize themselves with recent developments on new techniques and tools, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang, Erlang-like languages, functional programming, distribution, concurrency etc. We invite two types of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). Submission related to Erlang, Elixir, Scala/Akka, CloudHaskell, Lisp Flavoured Erlang, OCaml, and functional programming are welcome and encouraged. The maximum length for technical papers is restricted to 12 pages, but short papers (max. 6 pages) are welcomed as well. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 12 pages, but short papers (max. 6 pages) are welcomed as well. Workshop Co-Chairs Adrian Francalanza, University of Malta, Malta Vikt?ria F?rd?s, Cisco Systems, Sweden Program Committee (Note: the Workshop Co-Chairs are also committee members) Annette Bieniusa, University of Kaiserslautern, Germany Christopher S. Meiklejohn, Carnegie Mellon University, USA Clara Benac Earle, Universidad Politecnica de Madrid, Spain Claudio Antares Mezzina, IMT Lucca, Italy Emilio Tuosto, University of Leicester, UK Felix Mulder, Klarna AB, Sweden Francesco Cesarini, Erlang Solutions Ltd, UK Julien Lange, University of Kent, UK Kenji Rikitake, KRPEO, Japan Melinda T?th, ELTE E?tv?s Lor?nd University, Hungary Natalia Chechina, Bournemouth University, UK Rumyana Neykova, Brunel University, UK Scott Lystig Fritchie, Wallaroo, USA Thomas Arts, Quviq AB, Sweden Torben Hoffmann, Alert Logic, Denmark Important Dates Submissions due: Sun, May 19, 2019 Author notification: Fri June 14, 2019 Final submission for the publisher: Sun June 30, 2019 Workshop date: Sun August 18, 2019 Instructions to authors Papers must be submitted online via HotCRP (via the "Erlang2019" event). The submission page is https://erlang19.hotcrp.com Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Paper submissions will be considered for poster submission in the case they are not accepted as full papers. Venue & Registration Details For registration, please see the ICFP 2019 web site at: http://icfp19.sigplan.org/ Related Links ICFP 2019 web site: http://icfp19.sigplan.org/ Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/ Open Source Erlang: http://www.erlang.org/ HotCRP submission site: https://erlang19.hotcrp.com Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Attendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/CodeOfConduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterdmv@REDACTED Fri May 10 15:26:32 2019 From: peterdmv@REDACTED (Peter Dimitrov) Date: Fri, 10 May 2019 15:26:32 +0200 Subject: [erlang-questions] Should uri_string:dissect_query/1 be able to parse this? Message-ID: Hi, uri_string:dissect_query/1 is already fixed on master so it will be available in OTP-22: 1> uri_string:dissect_query("b=12&a"). [{"b","12"},{"a",true}] 2> BR/Peter -----Original Message----- From: erlang-questions-bounces@REDACTED On Behalf Of Lo?c Hoguin Sent: den 10 maj 2019 10:00 To: Marc Worrell ; Leo Liu Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Should uri_string:dissect_query/1 be able to parse this? Not just common, it's not an error. The parsing code must be https://url.spec.whatwg.org/#urlencoded-parsing to be correct. On 10/05/2019 09:50, Marc Worrell wrote: > A query argument without a ?=? is something you see quite often. > So in my opinion the uri_string module should be able to handle it. > > - Marc > > >> On 10 May 2019, at 04:31, Leo Liu wrote: >> >> uri_string is a solid module and great addition. I like using it >> whenever possible. But, >> >>> uri_string:dissect_query("b=12&a"). >> {error,missing_value,<<>>} >> >> whenever there is a key without a trailing =. >> >> Does it make more sense to be able to parse these query strings? >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> https://protect2.fireeye.com/url?k=1a7128cd-46f887a6-1a716856-0cc47ad >> 93ea2-f9a6a7cb2daffdbe&u=http://erlang.org/mailman/listinfo/erlang-qu >> estions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > https://protect2.fireeye.com/url?k=cb00f68b-978959e0-cb00b610-0cc47ad9 > 3ea2-579928f8286624c6&u=http://erlang.org/mailman/listinfo/erlang-ques > tions > -- Lo?c Hoguin https://protect2.fireeye.com/url?k=e60bd0f8-ba827f93-e60b9063-0cc47ad93ea2-123d568d944cd0be&u=https://ninenines.eu/ _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED https://protect2.fireeye.com/url?k=e5ae9822-b9273749-e5aed8b9-0cc47ad93ea2-efb6eef7993037ae&u=http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuna.prime@REDACTED Fri May 10 19:40:06 2019 From: kuna.prime@REDACTED (Karlo Kuna) Date: Fri, 10 May 2019 19:40:06 +0200 Subject: [erlang-questions] erlang.org/erldoc not available? Message-ID: it seems http://erlang.org/erldoc is down hello just wanted to ask if anyone knows when it will go up again? thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sat May 11 15:45:11 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 11 May 2019 09:45:11 -0400 Subject: [erlang-questions] erlang.org/erldoc not available? In-Reply-To: References: Message-ID: <20190511134510.GQ16387@ferdmbp.local> On 05/10, Karlo Kuna wrote: >it seems http://erlang.org/erldoc is down >hello just wanted to ask if anyone knows when it will go up again? > >From another thread on these mailing lists: erlang.org, i.e http download and mailing lists, documentation search, etc, will be down for the first half of the upcoming weekend (Friday 16:00 through Saturday 14:00 CEST) due to power maintenance work in the building. Sorry for any inconvenience. Best Regards From sdl.web@REDACTED Fri May 10 18:23:44 2019 From: sdl.web@REDACTED (Leo Liu) Date: Sat, 11 May 2019 00:23:44 +0800 Subject: [erlang-questions] Should uri_string:dissect_query/1 be able to parse this? In-Reply-To: (Peter Dimitrov's message of "Fri, 10 May 2019 15:26:32 +0200") References: Message-ID: On 2019-05-10 15:26 +0200, Peter Dimitrov wrote: > uri_string:dissect_query/1 is already fixed on master so it will be > available in OTP-22: > > 1> uri_string:dissect_query("b=12&a"). > [{"b","12"},{"a",true}] > 2> > > BR/Peter Thanks. That is great news. Is there a plan to fix it in OTP 21? Leo From zxq9@REDACTED Sat May 11 17:40:16 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Sun, 12 May 2019 00:40:16 +0900 Subject: [erlang-questions] erlang.org/erldoc not available? In-Reply-To: References: Message-ID: <3276627.s8AD5Gt86A@takoyaki> On 2019?5?10???? 19?40?06? JST Karlo Kuna wrote: > it seems http://erlang.org/erldoc is down > hello just wanted to ask if anyone knows when it will go up again? Yes it is down for scheduled maintenance. A doc mirror is available here: http://zxq9.com/erlang/docs/ Direct link to R21 manpage index: http://zxq9.com/erlang/docs/reg/21.0/doc/man_index.html Should be back up Sunday or Monday, depending on the schedule and your timezome. -Craig From petergi@REDACTED Sun May 12 07:05:11 2019 From: petergi@REDACTED (Peter J Etheridge) Date: Sun, 12 May 2019 15:05:11 +1000 Subject: [erlang-questions] export record to mnesia module Message-ID: <9a248e61e51662afcc59292d371cb08ef62a1fb7@webmail.iinet.net.au> Dear Friends, Un & Pw are captured in a record Usr from a wx module. Usr is to be stored in mnesia in module(usrdb). export_fun() does not trouble Dialyzer. Mnesia starts, but does not create a new record; export_fun(Pw, Un, Pwv, Unv, Usr) -> case wxPasswordEntryDialog:connect(Pw, command_button_clicked, [{userData, Pwv}]) of ? ok -> ??? case wxTextEntryDialog:connect(Un, command_button_clicked, [{userData, Unv}]) of ????? ok -> ??? ? register(usrdb, spawn_link(usrdb, handle_cast, [Usr])), ??? ??? usrdb ! {send, Usr}, ??? ??? F = fun() -> ??????? receive ??????????? Usr = #usr_record{un = Unv, pas = Pwv} -> ??????????????? mnesia:write(usr_table, Usr, write) ?????? ??? ??? ??? after 0 -> ??????? receive ??????????? Any -> ??????????????? Any ??????????????????? end ??????????????? end ??????????? end, ??????? mnesia:transaction(F) ??? end end, export_fun(Pw, Un, Pwv, Unv, Usr). What does this code lack? Thank you in advance, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Sun May 12 14:00:54 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 12 May 2019 14:00:54 +0200 Subject: [erlang-questions] export record to mnesia module In-Reply-To: <9a248e61e51662afcc59292d371cb08ef62a1fb7@webmail.iinet.net.au> References: <9a248e61e51662afcc59292d371cb08ef62a1fb7@webmail.iinet.net.au> Message-ID: On Sun, May 12, 2019 at 7:05 AM Peter J Etheridge wrote: > > Dear Friends, > Un & Pw are captured in a record Usr from a wx module. > Usr is to be stored in mnesia in module(usrdb). > export_fun() does not trouble Dialyzer. Mnesia starts, but does not create a new record; > > export_fun(Pw, Un, Pwv, Unv, Usr) -> > case wxPasswordEntryDialog:connect(Pw, command_button_clicked, [{userData, Pwv}]) of > ok -> > case wxTextEntryDialog:connect(Un, command_button_clicked, [{userData, Unv}]) of > ok -> > register(usrdb, spawn_link(usrdb, handle_cast, [Usr])), > usrdb ! {send, Usr}, > F = fun() -> > receive > Usr = #usr_record{un = Unv, pas = Pwv} -> > mnesia:write(usr_table, Usr, write) > after 0 -> > receive > Any -> > Any > end > end > end, > mnesia:transaction(F) > end > end, > export_fun(Pw, Un, Pwv, Unv, Usr). > > What does this code lack? This code has a number of problems. 1. The process executing export_fun/5 and F/0 expects to receive a message, but you never pass its Pid anywhere, so it's unclear how that's going to happen. I'm assuming you intended to include self() in the tuple sent to usrdb, and have usrdb send some #usr_record{} back. 2. The F/0 function requires that a specifically-formatted message is present in its calling process' mailbox, and if that's not the case, e.g. due to timing between the processes involved, it throws away the next available message. This is very racy design. 3. The F/0 function's receive matches on variables already bound in export_fun/5, so it will only match if sent a usr_record identical to the one passed to export_fun/5, whose fields also exactly match the other parameters passed to export_fun/5. If this is intentional it's highly redundant, if not you need to change the variable names to avoid matching where you expect plain binding. 4. In each iteration you spawn and link a process, and register it as userdb. If that process terminates it will take the process executing export_fun/5 down with it. If it does not immediately terminate then in the next iteration of export_fun/5 the attempt to register the next instance of that process will crash the export_fun/5 process, and via its link the previous usrdb process. I cannot believe this behaviour is intentional. 5. You spawn a process starting in usrdb:handle_cast/1. A handle_cast function would normally occur in a gen_server, and have arity 2. And you wouldn't start a gen_server that way. 6. You pass Usr twice to the usrdb process, both in the initial spawn and then in an explicit message. This looks odd and redundant. 7. Your attempt to issue a transaction executes the receive inside the transaction function. As receives aren't transactional operations, I would have expected the transaction to be executed inside the receive's successful path. To start with, usrdb should probably be a semi-permanent separate process, so you should't mess with spawn_link or register in the loop. Also, the signalling between the processes is extremely fragile (and incorrect as is), so you would benefit from changing usrdb to be a standard gen_server and use gen_server:call or similar to communicate with it. From okaprinarjaya@REDACTED Sun May 12 16:45:02 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sun, 12 May 2019 21:45:02 +0700 Subject: [erlang-questions] Distibuted-Erlang practical case studies / examples Message-ID: Hi, I just learn about how to ping a remote erlang node, call erlang program in a remote erlang node by following this chapter https://learnyousomeerlang.com/distribunomicon . But, i can't imagine what kind of simple solution that i can build by utilizing Erlang's distributed behavior / feature / ability. Ok, first, i need some simple case studies utilizingg distributed behavior / ability from erlang. Second, Why do we utilizing distributed behavior / ability of erlang? Or in other words, which is better? utilizing rpc:call() or call other service in other remote node just through HTTP (REST maybe) ? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Sun May 12 17:54:40 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sun, 12 May 2019 22:54:40 +0700 Subject: [erlang-questions] Distibuted-Erlang practical case studies / examples In-Reply-To: References: Message-ID: I need more concrete examples / cases please. Thank you Pada tanggal Min, 12 Mei 2019 pukul 21.57 T Ty menulis: > SOAP/REST is great if you have to interface with non-Erlang systems. For > other Erlang systems I prefer using direct process to process message > sending instead of rpc:call although some people do favor rpc:call. Bit of > personal preference and background. > > As to why or case study using distributed system just look at > microservices. Anything that would fit into microservices would map > one-to-one into Erlang. > > On Sun, May 12, 2019 at 3:45 PM I Gusti Ngurah Oka Prinarjaya < > okaprinarjaya@REDACTED> wrote: > >> Hi, >> >> I just learn about how to ping a remote erlang node, call erlang program >> in a remote erlang node by following this chapter >> https://learnyousomeerlang.com/distribunomicon . >> >> But, i can't imagine what kind of simple solution that i can build by >> utilizing Erlang's distributed behavior / feature / ability. >> >> Ok, first, i need some simple case studies utilizingg distributed >> behavior / ability from erlang. >> Second, Why do we utilizing distributed behavior / ability of erlang? Or >> in other words, >> which is better? utilizing rpc:call() or call other service in other >> remote node just through HTTP (REST maybe) ? >> >> Thank you >> >> >> _______________________________________________ >> 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 Mon May 13 05:31:14 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 12 May 2019 23:31:14 -0400 Subject: [erlang-questions] Distibuted-Erlang practical case studies / examples In-Reply-To: References: Message-ID: Wikipedia gives these reasons for distribution of data: Cloud storage is:[6] Made up of many distributed resources, but still acts as one, either in a federated[8] or a cooperative storage cloudarchitecture Highly fault tolerant through redundancy and distribution of data Highly durable through the creation of versioned copies Typically eventually consistent with regard to data replicas[9] https://en.m.wikipedia.org/wiki/Cloud_storage Distributed systems are also used to process ?big data.? Look here: Survey of Parallel Processing on Big Data https://pdfs.semanticscholar.org/a7a8/58914aae88752d095d9602364a8b9410f471.pdf See this to see how a Erlang fits into the picture: Evaluating Scalable Distributed Erlang for Scalability and Reliability https://ieeexplore.ieee.org/ielx7/71/7979644/07820204.pdf?tp=&arnumber=7820204&isnumber=7979644&ref=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8= Leofs is an interesting open source project that is striving to push distribution across global data centers: https://leo-project.net/leofs/ You can study source here: https://github.com/leo-project/leofs Best wishes, LRP Sent from my iPad > On May 12, 2019, at 11:54 AM, I Gusti Ngurah Oka Prinarjaya wrote: > > I need more concrete examples / cases please. > > Thank you > > > Pada tanggal Min, 12 Mei 2019 pukul 21.57 T Ty menulis: >> SOAP/REST is great if you have to interface with non-Erlang systems. For other Erlang systems I prefer using direct process to process message sending instead of rpc:call although some people do favor rpc:call. Bit of personal preference and background. >> >> As to why or case study using distributed system just look at microservices. Anything that would fit into microservices would map one-to-one into Erlang. >> >>> On Sun, May 12, 2019 at 3:45 PM I Gusti Ngurah Oka Prinarjaya wrote: >>> Hi, >>> >>> I just learn about how to ping a remote erlang node, call erlang program in a remote erlang node by following this chapter https://learnyousomeerlang.com/distribunomicon . >>> >>> But, i can't imagine what kind of simple solution that i can build by utilizing Erlang's distributed behavior / feature / ability. >>> >>> Ok, first, i need some simple case studies utilizingg distributed behavior / ability from erlang. >>> Second, Why do we utilizing distributed behavior / ability of erlang? Or in other words, >>> which is better? utilizing rpc:call() or call other service in other remote node just through HTTP (REST maybe) ? >>> >>> Thank you >>> >>> >>> _______________________________________________ >>> 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 attila.r.nohl@REDACTED Mon May 13 09:59:05 2019 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 13 May 2019 09:59:05 +0200 Subject: [erlang-questions] Distibuted-Erlang practical case studies / examples In-Reply-To: References: Message-ID: Hello! In the original usecase of Erlang (the AXD) the Erlang nodes were running on "cards" in different slots in the same chassis. The distribution was used for example to achieve high availability, so in the unlikely event that a node went down, the state was duplicated on the stand-by node. This was implemented probably before HTTP REST was invented at all. Don't forget, the reason why HTTP REST APIs exists in the first place is that today's internet is not an "everybody connected to everybody" network, but a bunch of (fire)walled "gardens" connected to each other where the firewalls don't let anything pass through, but HTTP. So if you control the network between your nodes, you can use Erlang distribution, if you don't, you probably have no other choice than to implement something over HTTP. I Gusti Ngurah Oka Prinarjaya ezt ?rta (id?pont: 2019. m?j. 12., V, 16:45): > > Hi, > > I just learn about how to ping a remote erlang node, call erlang program in a remote erlang node by following this chapter https://learnyousomeerlang.com/distribunomicon . > > But, i can't imagine what kind of simple solution that i can build by utilizing Erlang's distributed behavior / feature / ability. > > Ok, first, i need some simple case studies utilizingg distributed behavior / ability from erlang. > Second, Why do we utilizing distributed behavior / ability of erlang? Or in other words, > which is better? utilizing rpc:call() or call other service in other remote node just through HTTP (REST maybe) ? > > Thank you > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From Oliver.Korpilla@REDACTED Mon May 13 10:22:00 2019 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Mon, 13 May 2019 10:22:00 +0200 Subject: [erlang-questions] Distibuted-Erlang practical case studies / examples In-Reply-To: References: Message-ID: Hello, we use distributed BEAM nodes connected by the Erlang Distribution Protocol in several applications at my workplace. One application had one node handling all the central functions while the handling of users (potentially 10,000) was isolated into another node. If we needed the ability to handle more users than the current amount of connected nodes could handle, we connected more nodes. We used both message passing and distributed Mnesia in this application. We're also building a load generator. It will run through messaging scenarios useful in a Telco application, trying to fill as many parallel queues in the system under test as possible. Again, the choice is to run them on distributed BEAM nodes. The communication between nodes is based mostly on message passing and synchronous gen_server calls where needed. (Though in this application, once everything is set up, no more messages will be passed between nodes and the configured processes will just fire away at their network interfaces according to pre-configured scenarios.) We basically always opt to add more BEAM nodes when we want to utilize more cores distributed over more machines within the same network. The main advantage of BEAM nodes I see in my work is that where something runs can be very flexible when needed. We used :gproc and now :syn to benefit from that flexibility, freeing us from the need to know where something is run. For example: I had to design an application without knowing whether the underlying system would allow us to start BEAM with multi-core enabled or if each BEAM node would be pinned to just one core. (It was pretty clear that one core would not cut it for our requirements.) I opted to implement it as separate communicating applications that can be deployed into multiple BEAM nodes if needed. In the end, this wasn't necessary, so we deployed all parts into the same BEAM node. All we needed to change was the release bundling of the software but not the software itself. When we learned that we need to scale that application, this initial design decision in turn enabled us to do so. Spreading things out is easy with BEAM but one has to consider the performance implications. Most communication should happen within a node, for example. So, these were my use cases. Cheers, Oliver ? Gesendet:?Sonntag, 12. Mai 2019 um 16:45 Uhr Von:?"I Gusti Ngurah Oka Prinarjaya" An:?Erlang Betreff:?[erlang-questions] Distibuted-Erlang practical case studies / examples Hi, ? I just learn about how to ping a remote erlang node,? call erlang program in a remote erlang node by following this chapter?https://learnyousomeerlang.com/distribunomicon?.? ? But, i can't imagine what kind of simple solution that i can build by utilizing Erlang's distributed behavior / feature / ability. ? Ok, first, i need some simple case studies utilizingg distributed behavior / ability from erlang. Second, Why do we utilizing distributed behavior / ability of erlang? Or in other words, which is better? utilizing rpc:call() or call other service in other remote node just through HTTP (REST maybe) ?? Thank you ? ?_______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] From okaprinarjaya@REDACTED Mon May 13 20:17:10 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Tue, 14 May 2019 01:17:10 +0700 Subject: [erlang-questions] Distibuted-Erlang practical case studies / examples In-Reply-To: References: Message-ID: Thank you everyone :) Pada tanggal Sen, 13 Mei 2019 pukul 15.22 Oliver Korpilla < Oliver.Korpilla@REDACTED> menulis: > Hello, > > we use distributed BEAM nodes connected by the Erlang Distribution > Protocol in several applications at my workplace. > > One application had one node handling all the central functions while the > handling of users (potentially 10,000) was isolated into another node. If > we needed the ability to handle more users than the current amount of > connected nodes could handle, we connected more nodes. We used both message > passing and distributed Mnesia in this application. > > We're also building a load generator. It will run through messaging > scenarios useful in a Telco application, trying to fill as many parallel > queues in the system under test as possible. Again, the choice is to run > them on distributed BEAM nodes. The communication between nodes is based > mostly on message passing and synchronous gen_server calls where needed. > (Though in this application, once everything is set up, no more messages > will be passed between nodes and the configured processes will just fire > away at their network interfaces according to pre-configured scenarios.) > > We basically always opt to add more BEAM nodes when we want to utilize > more cores distributed over more machines within the same network. > > The main advantage of BEAM nodes I see in my work is that where something > runs can be very flexible when needed. We used :gproc and now :syn to > benefit from that flexibility, freeing us from the need to know where > something is run. For example: > > I had to design an application without knowing whether the underlying > system would allow us to start BEAM with multi-core enabled or if each BEAM > node would be pinned to just one core. (It was pretty clear that one core > would not cut it for our requirements.) I opted to implement it as separate > communicating applications that can be deployed into multiple BEAM nodes if > needed. In the end, this wasn't necessary, so we deployed all parts into > the same BEAM node. All we needed to change was the release bundling of the > software but not the software itself. > > When we learned that we need to scale that application, this initial > design decision in turn enabled us to do so. Spreading things out is easy > with BEAM but one has to consider the performance implications. Most > communication should happen within a node, for example. > > So, these were my use cases. > > Cheers, > Oliver > > > Gesendet: Sonntag, 12. Mai 2019 um 16:45 Uhr > Von: "I Gusti Ngurah Oka Prinarjaya" > An: Erlang > Betreff: [erlang-questions] Distibuted-Erlang practical case studies / > examples > > Hi, > > I just learn about how to ping a remote erlang node, call erlang program > in a remote erlang node by following this chapter > https://learnyousomeerlang.com/distribunomicon . > > But, i can't imagine what kind of simple solution that i can build by > utilizing Erlang's distributed behavior / feature / ability. > > Ok, first, i need some simple case studies utilizingg distributed behavior > / ability from erlang. > Second, Why do we utilizing distributed behavior / ability of erlang? Or > in other words, > which is better? utilizing rpc:call() or call other service in other > remote node just through HTTP (REST maybe) ? > > Thank you > > _______________________________________________ erlang-questions mailing > list erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From by@REDACTED Tue May 14 02:04:16 2019 From: by@REDACTED (by) Date: Tue, 14 May 2019 08:04:16 +0800 Subject: [erlang-questions] www.erlang.org does not update MAILINGLIST HEADLINES Message-ID: <6036F645-F02D-4A63-8AE0-CCD495FACC65@meetlost.com> Hello List, I found the "MAILINGLIST HEADLINES? on www.erlang.org does not updated for a while. Is there any issue with the process doing that task? Best Regards, Yao -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterdmv@REDACTED Tue May 14 08:53:22 2019 From: peterdmv@REDACTED (Peter Dimitrov) Date: Tue, 14 May 2019 08:53:22 +0200 Subject: [erlang-questions] Should uri_string:dissect_query/1 be able to parse this? Message-ID: Hi, There are no such plans at the moment due to the coming release of OTP-22. BR/Peter -----Original Message----- From: Leo Liu Sent: den 10 maj 2019 18:24 To: Peter Dimitrov Cc: Lo?c Hoguin ; Marc Worrell ; erlang-questions@REDACTED Subject: Re: Should uri_string:dissect_query/1 be able to parse this? On 2019-05-10 15:26 +0200, Peter Dimitrov wrote: > uri_string:dissect_query/1 is already fixed on master so it will be > available in OTP-22: > > 1> uri_string:dissect_query("b=12&a"). > [{"b","12"},{"a",true}] > 2> > > BR/Peter Thanks. That is great news. Is there a plan to fix it in OTP 21? Leo -------------- next part -------------- An HTML attachment was scrubbed... URL: From petergi@REDACTED Tue May 14 09:50:56 2019 From: petergi@REDACTED (Peter J Etheridge) Date: Tue, 14 May 2019 17:50:56 +1000 Subject: [erlang-questions] CAM43=SMSS_eooFxjfhVhReZTik82gwb9VQ_bg7EfjA2iv5G-+Q@mail.gmail.com Message-ID: <3f0f69ee1915a240ad3522230819793bcdb0d862@webmail.iinet.net.au> Thank you for your guidance Dan & Mikael. Implementing your improvements; in the wx module pw.erl export_usr(Pw, Un, Pwv, Unv, Usr) -> case wxPasswordEntryDialog:connect(Pw, command_button_clicked, [{userData, Pwv}]) of ? ok -> ??? case wxTextEntryDialog:connect(Un, command_button_clicked, [{userData, Unv}]) of ????? ok -> ??????? io:format("~p: ~p ~n", [Usr, [#usr_record{un = Unv, pas = Pwv}]]), ??? Pid = spawn(usrdb, handle_usr, [Usr]), ??? ? register(usrdb, Pid), ??? ? Pid ! {self(), Usr} ??? end end, export_usr(Pw, Un, Pwv, Unv, Usr). Trying to send this value of Usr to; the mnesia module usrdb.erl handle_usr(Usr) when is_record(Usr, usr_record)-> ??? io:format("~p ~n", [Usr]), ??? ??? {atomic, [Usr]} = mnesia:transaction(fun() -> ??? ??? ??? mnesia:write(usr_table, Usr, write) end), ??? Usr. While this runs, no record in mnesia is found. The first pw.erl function builds the window to gather user data before wx:show(Frame). In the second function export_usr/5, wxPasswordEntryDialog etc is a repetition. A variable can only be given a value once in its scope. Does its scope end at wx:show(Frame)? (At the ' . ' of the first function?) If so, what is the correct procedure to copy a variable's value to a subsequent function in a wx module? Is there a better method for writing user data from a wx module into an mnesia table? Thank you once again in advance for your insights. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik.x.nord@REDACTED Tue May 14 14:29:32 2019 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Tue, 14 May 2019 12:29:32 +0000 Subject: [erlang-questions] Patch Package OTP-22.0 Released Message-ID: <1557836972.31047.70.camel@ericsson.com> Erlang/OTP 22 is a new major release with new features and improvements as well as incompatibilities. For a deeper dive into the hightligts of the OTP 22 release, you can read our blog here: http://blog.erlang.org/OTP-22-Highlights/ Potential Incompatibilities * gen_* behaviours: If logging of the last N messages through sys:log/2,3 is active for the server, this log is included in the terminate report * reltool: A new element, Opts, can now be included in a rel tuple in the reltool release specific configuration format: {rel, Name, Vsn, RelApps, Opts}. * All external pids/ports/refs created by erlang:list_to_pid and similar functions now compare equal to any other pid/port/ref with same number from that node. * The old legacy erl_interface library is deprecated as of OTP 22, and will be removed in OTP 23. This does not apply to the ei library. * VxWorks is deprecated as of OTP 22 and will be removed in OTP 23. Erts: * Support for Erlang Distribution protocol to split the payload of large signals into several fragments. * ETS option write_concurrency now also effects and improves scalability of ordered_set tables. * The length/1 BIF used to calculate the length of the list in one go without yielding, even if the list was very long. Now it yields when called with long lists. * A new (still experimental) module socket is introduced. It is implemented as a NIF and the idea is that it shall be as "close as possible" to the OS level socket interface. * Added the NIF function enif_term_type, which helps avoid long sequences of enif_is_xyz by returning the type of the given term. This is especially helpful for NIFs that serialize terms, such as JSON encoders, where it can improve both performance and readability. Compiler: * The compiler has been rewritten to internally use an intermediate representation based on Static Single Assignment (SSA). The new intermediate representation makes more optimizations possible. * The binary matching optimizations are now applicable in many more circumstances than before. * Type optimizations are now applied across local function calls, and will remove a lot more redundant type tests than before. * All compiler options that can be given in the source file can now be given in the option list on the command line for erlc. * In OTP 22, HiPE (the native code compiler) is not fully functional. The reasons for this are new BEAM instructions for binary matching that the HiPE native code compiler does not support. If erlc is invoked with the +native option, and if any of the new binary matching instructions are used, the compiler will issue a warning and produce a BEAM file without native code. Standard libraries: * Cover now uses the counters module instead of ets for updating counters. The new function cover:local_only/0 allows running Cover in a restricted but faster local-only mode. The increase in speed will vary depending on the type of code being cover-compiled, as an example the compiler test suite runs more than twice as fast with the new Cover. * A simple socket API is provided through the socket module. This is a low level API that does not replace gen_[tcp|udp|sctp]. It is intended to eventually replace the inet driver. It also provides a basic API that facilitates the implementation of other protocols than TCP, UDP and SCTP. Known issues are; No support for the Windows OS (currently), a small term leakage. This feature will be classed as experimental in OTP 22. * SSL: now uses the new logger API, including log levels and verbose debug logging. * SSL: Basic support for TLS 1.3 Server for experimental use. * Crypto: The new hash_info/1 and cipher_info/1 functions returns maps with information about the hash or cipher in the argument. For more details see http://erlang.org/download/otp_src_22.0.readme Pre built versions for Windows can be fetched here: http://erlang.org/download/otp_win32_22.0.exe http://erlang.org/download/otp_win64_22.0.exe Online documentation can be browsed here: http://erlang.org/doc/search/ The Erlang/OTP source can also be found at GitHub on the official Erlang repository: https://github.com/erlang/otp/releases/tag/OTP-22.0 Make sure to report any and all bugs here: https://bugs.erlang.org/ Thank you for all your contributions! -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik.x.nord@REDACTED Tue May 14 15:12:32 2019 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Tue, 14 May 2019 13:12:32 +0000 Subject: [erlang-questions] Erlang/OTP 22.0 has been released Message-ID: <1557839551.31047.74.camel@ericsson.com> Erlang/OTP 22 is a new major release with new features and improvements as well as incompatibilities. For a deeper dive into the hightligts of the OTP 22 release, you can read our blog here: http://blog.erlang.org/OTP-22-Highlights/ Potential Incompatibilities * gen_* behaviours: If logging of the last N messages through sys:log/2,3 is active for the server, this log is included in the terminate report * reltool: A new element, Opts, can now be included in a rel tuple in the reltool release specific configuration format: {rel, Name, Vsn, RelApps, Opts}. * All external pids/ports/refs created by erlang:list_to_pid and similar functions now compare equal to any other pid/port/ref with same number from that node. * The old legacy erl_interface library is deprecated as of OTP 22, and will be removed in OTP 23. This does not apply to the ei library. * VxWorks is deprecated as of OTP 22 and will be removed in OTP 23. Erts: * Support for Erlang Distribution protocol to split the payload of large signals into several fragments. * ETS option write_concurrency now also effects and improves scalability of ordered_set tables. * The length/1 BIF used to calculate the length of the list in one go without yielding, even if the list was very long. Now it yields when called with long lists. * A new (still experimental) module socket is introduced. It is implemented as a NIF and the idea is that it shall be as "close as possible" to the OS level socket interface. * Added the NIF function enif_term_type, which helps avoid long sequences of enif_is_xyz by returning the type of the given term. This is especially helpful for NIFs that serialize terms, such as JSON encoders, where it can improve both performance and readability. Compiler: * The compiler has been rewritten to internally use an intermediate representation based on Static Single Assignment (SSA). The new intermediate representation makes more optimizations possible. * The binary matching optimizations are now applicable in many more circumstances than before. * Type optimizations are now applied across local function calls, and will remove a lot more redundant type tests than before. * All compiler options that can be given in the source file can now be given in the option list on the command line for erlc. * In OTP 22, HiPE (the native code compiler) is not fully functional. The reasons for this are new BEAM instructions for binary matching that the HiPE native code compiler does not support. If erlc is invoked with the +native option, and if any of the new binary matching instructions are used, the compiler will issue a warning and produce a BEAM file without native code. Standard libraries: * Cover now uses the counters module instead of ets for updating counters. The new function cover:local_only/0 allows running Cover in a restricted but faster local-only mode. The increase in speed will vary depending on the type of code being cover-compiled, as an example the compiler test suite runs more than twice as fast with the new Cover. * A simple socket API is provided through the socket module. This is a low level API that does not replace gen_[tcp|udp|sctp]. It is intended to eventually replace the inet driver. It also provides a basic API that facilitates the implementation of other protocols than TCP, UDP and SCTP. Known issues are; No support for the Windows OS (currently), a small term leakage. This feature will be classed as experimental in OTP 22. * SSL: now uses the new logger API, including log levels and verbose debug logging. * SSL: Basic support for TLS 1.3 Server for experimental use. * Crypto: The new hash_info/1 and cipher_info/1 functions returns maps with information about the hash or cipher in the argument. For more details see http://erlang.org/download/otp_src_22.0.readme Pre built versions for Windows can be fetched here: http://erlang.org/download/otp_win32_22.0.exe http://erlang.org/download/otp_win64_22.0.exe Online documentation can be browsed here: http://erlang.org/doc/search/ The Erlang/OTP source can also be found at GitHub on the official Erlang repository: https://github.com/erlang/otp/releases/tag/OTP-22.0 Make sure to report any and all bugs here: https://bugs.erlang.org/ Thank you for all your contributions! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue May 14 23:12:47 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 14 May 2019 17:12:47 -0400 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= Message-ID: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> Hello, My Mickey-the-Dunce ignorance and curiosity has led me to explore Linux containers. Very cool. Then, a recent conversation with Oliver Korpilla tweaked my wonder nerve: Is it possible/practical to run multiple BEAM nodes on a single Linux node? Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services? each for a different client. Has anyone ever done anything along this line? Best wishes, LRP Sent from my iPad From codmajik@REDACTED Tue May 14 23:36:44 2019 From: codmajik@REDACTED (Chinedu Okonkwo) Date: Tue, 14 May 2019 21:36:44 +0000 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> Message-ID: That is pretty much what erlang release is. I think its one of the reason docker/containers didn't catch on in the erlang community. The major problem you may face running it especially in distributed erlang mode may be name collusion in empd On Tue, May 14, 2019 at 9:13 PM Lloyd R. Prentice wrote: > Hello, > > My Mickey-the-Dunce ignorance and curiosity has led me to explore Linux > containers. Very cool. Then, a recent conversation with Oliver Korpilla > tweaked my wonder nerve: > > Is it possible/practical to run multiple BEAM nodes on a single Linux node? > > Assume each BEAM node supports an identical web application with a Mnesia > backend serving a set of CRUD services? each for a different client. > > Has anyone ever done anything along this line? > > Best wishes, > > LRP > > Sent from my iPad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_ribe@REDACTED Tue May 14 23:45:18 2019 From: scott_ribe@REDACTED (Scott Ribe) Date: Tue, 14 May 2019 15:45:18 -0600 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> Message-ID: > On May 14, 2019, at 3:36 PM, Chinedu Okonkwo wrote: > > Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services? each for a different client. Perfectly possible, but also pointless. You'd normally just have one BEAM node with one erlang process per client. From lloyd@REDACTED Wed May 15 00:58:12 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 14 May 2019 18:58:12 -0400 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> Message-ID: Hi Scott, Can you elaborate please? Thanks, Lloyd Sent from my iPad On May 14, 2019, at 5:45 PM, Scott Ribe wrote: >> On May 14, 2019, at 3:36 PM, Chinedu Okonkwo wrote: >> >> Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services? each for a different client. > > Perfectly possible, but also pointless. You'd normally just have one BEAM node with one erlang process per client. From lloyd@REDACTED Wed May 15 01:59:12 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 14 May 2019 19:59:12 -0400 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> Message-ID: <5993C783-17C2-48A6-A0BB-8E1F5849EB66@writersglen.com> Hi Chinedu, So operationally, would one install a release for each user in separate directories? My musings, uninformed by experience, have progressed more or less along this line: ? Data loss is totally unacceptable to the users I have in mind. ? There could be many users, each with his/her own corpus of data; no intersection. ? Traffic per user would be quite low. ? Data corpus per user would be fairly small. ? Users come and go. When they go, they want to take their data. Some may want to return and pickup where they left off. ? The traditional solution would be a capacious, maybe even distributed, database behind a single, well maybe load balanced, front end. ? But this means that there could potentially be an increasing volume of ?dead,? e.g. unused data, or one would need a way to archive data when a user leaves. In this second case, archiving and restoring data over many users could tie up a great deal of db?s bandwidth. ? Fanciful solution I: Give each user his/her own independent website. ? Linux containers might make this possible. ? Transactions are not an issue. ? A small Mnesia db or even dets db per user would suffice. ? Linux containers could be deployed over multiple hardware or VPS nodes, lowering hardware failure risk and making it relatively easy to scale from just a few users to many many. ? LXD provides tools that would make it relatively easy to induct new users and replicate user sites. ? But would it be economically feasible? ? Fanciful solution II: Multiple BEAM nodes per Linux node. ? Hmmm... might have to functionally replicate tools that LXD already provides. ? But it might be more resource efficient. ? Can it even work? And so, my head spins for lack of experience. And so, I?d much appreciate insight and guidance from experienced hands. All the best, Lloyd Sent from my iPad > On May 14, 2019, at 5:36 PM, Chinedu Okonkwo wrote: > > That is pretty much what erlang release is. > > I think its one of the reason docker/containers didn't catch on in the erlang community. The major problem you may face running it especially in distributed erlang mode may be name collusion in empd > >> On Tue, May 14, 2019 at 9:13 PM Lloyd R. Prentice wrote: >> Hello, >> >> My Mickey-the-Dunce ignorance and curiosity has led me to explore Linux containers. Very cool. Then, a recent conversation with Oliver Korpilla tweaked my wonder nerve: >> >> Is it possible/practical to run multiple BEAM nodes on a single Linux node? >> >> Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services? each for a different client. >> >> Has anyone ever done anything along this line? >> >> Best wishes, >> >> LRP >> >> Sent from my iPad >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From codmajik@REDACTED Wed May 15 02:50:23 2019 From: codmajik@REDACTED (Chinedu Okonkwo) Date: Wed, 15 May 2019 00:50:23 +0000 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: <5993C783-17C2-48A6-A0BB-8E1F5849EB66@writersglen.com> References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> <5993C783-17C2-48A6-A0BB-8E1F5849EB66@writersglen.com> Message-ID: <5cdb6252.1c69fb81.2ca83.2030@mx.google.com> Hi Lloyd, Unless each user will directly have access to the erlang node (via remsh) or there is a compliance requirement at play, I will like to re-iterate Scott?s point. The is approach is pointless. Erlang release is portable (per OS; so a release created on Linux only contain VM for linux), like every portable software all you need is extract and run the script. But like every application you hit the same limitation, if this is a network/web app (which I assume it is), then they will each have to be configured on different ports, because multiple applications can?t listen on same port (there are some exceptions to this), you may want to jail the application into certain folders so they don?t file:read_file(?/etc/passwd?) on you. There will also be the backup/restore systems you will have to develop, the gateway to handle routing a user to the right instance of the app or distribute a host:port url for each user, a lot of other things you will need just to make this operational. As I said earlier this approach is almost pointless. My take will be 1. You are better off implementing this segregation in the application layer, even if there are different apps you can route the user to the said app quite easily. Segregation can be handled in the app, you can have one dets per user or one table per user in mnesia in a single vm, you will also have all the programmatic tools to handle user idleness and shutdown unused resources. >From your description, I think the traditional solution is also a good solution. If anything you will likely underutilize your resources. 2. If necessary, just use a container then workout the infrastructure to route the requests, this will need some service discovery or a manual management of the route map (eg: nginx config). But the benefit of using this instead of a raw deployment is that a lot of the issues listed have solutions that have been tested. From: Lloyd R. Prentice Sent: Tuesday, 14 May 2019 11:59 PM To: Chinedu Okonkwo Cc: Erlang Questions Subject: Re: [erlang-questions] Multiple BEAM nodes on one Linux node ? a thought experiment Hi Chinedu, So operationally, would one install a release for each user in separate directories? My musings, uninformed by experience, have progressed more or less along this line: ? Data loss is totally unacceptable to the users I have in mind. ? There could be many users, each with his/her own corpus of data; no intersection. ? Traffic per user would be quite low.? ? Data corpus per user would be fairly small.? ? Users come and go. When they go, they want to take their data. Some may want to return and pickup where they left off. ? The traditional solution would be a capacious, maybe even distributed, database behind a single, well maybe load balanced, front end.? ? But this means that there could potentially be an increasing volume of ?dead,? e.g. unused data, or one would need a way to archive data when a user leaves. In this second case, archiving and restoring data over many users could tie up a great deal of db?s bandwidth. ? Fanciful solution I: Give each user his/her own independent website.? ? Linux containers might make this possible. ? Transactions are not an issue. ? A small Mnesia db or even dets db per user would suffice. ? Linux containers could be deployed over multiple hardware or VPS nodes, lowering hardware failure risk and making it relatively easy to scale from just a few users to many many. ? LXD provides tools that would make it relatively easy to induct new users and replicate user sites. ? But would it be economically feasible? ? Fanciful solution II: ?Multiple BEAM nodes per Linux node. ? Hmmm... might have to functionally replicate tools that LXD already provides. ? But it might be more resource efficient. ? Can it even work? And so, my head spins for lack of experience. And so, I?d much appreciate insight and guidance from experienced hands. All the best, Lloyd Sent from my iPad On May 14, 2019, at 5:36 PM, Chinedu Okonkwo wrote: That is pretty much what erlang release is. I think its one of the reason docker/containers didn't catch on in the erlang community. The major problem you may face running it especially in distributed erlang mode may be name collusion in empd On Tue, May 14, 2019 at 9:13 PM Lloyd R. Prentice wrote: Hello, My Mickey-the-Dunce ignorance and curiosity has led me to explore Linux containers. Very cool. Then, a recent conversation with Oliver Korpilla tweaked my wonder nerve: Is it possible/practical to run multiple BEAM nodes on a single Linux node? Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services? each for a different client. Has anyone ever done anything along this line? Best wishes, LRP Sent from my iPad _______________________________________________ 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 Wed May 15 04:06:02 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 14 May 2019 22:06:02 -0400 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: <5cdb6252.1c69fb81.2ca83.2030@mx.google.com> References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> <5993C783-17C2-48A6-A0BB-8E1F5849EB66@writersglen.com> <5cdb6252.1c69fb81.2ca83.2030@mx.google.com> Message-ID: Hi Chinedu, > ?...one dets per user or one table per user in mnesia...? This is very interesting. How would this work for archiving and restoring user data? Can?t tell you how much I appreciate your input. Best, Lloyd Sent from my iPad > On May 14, 2019, at 8:50 PM, Chinedu Okonkwo wrote: > > one table per user in mnesia From lloyd@REDACTED Wed May 15 04:39:14 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 14 May 2019 22:39:14 -0400 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: <5cdb6252.1c69fb81.2ca83.2030@mx.google.com> References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> <5993C783-17C2-48A6-A0BB-8E1F5849EB66@writersglen.com> <5cdb6252.1c69fb81.2ca83.2030@mx.google.com> Message-ID: <799D4B93-DA31-48C9-AAF3-B763DA5DF761@writersglen.com> Ah, reading the Mnesia docs, I see how this can work. You?ve helped clarify many things. Many thanks, Lloyd Sent from my iPad > On May 14, 2019, at 8:50 PM, Chinedu Okonkwo wrote: > > Hi Lloyd, > > Unless each user will directly have access to the erlang node (via remsh) or there is a compliance requirement at play, I will like to re-iterate Scott?s point. The is approach is pointless. > > Erlang release is portable (per OS; so a release created on Linux only contain VM for linux), like every portable software all you need is extract and run the script. > > But like every application you hit the same limitation, if this is a network/web app (which I assume it is), then they will each have to be configured on different ports, > because multiple applications can?t listen on same port (there are some exceptions to this), you may want to jail the application into certain folders so they don?t file:read_file(?/etc/passwd?) on you. There will also be the backup/restore systems you will have to develop, the gateway to handle routing a user to the right instance of the app or distribute a host:port url for each user, a lot of other things you will need just to make this operational. As I said earlier this approach is almost pointless. > > My take will be > You are better off implementing this segregation in the application layer, even if there are different apps you can route the user to the said app quite easily. Segregation can be handled in the app, you can have one dets per user or one table per user in mnesia in a single vm, you will also have all the programmatic tools to handle user idleness and shutdown unused resources. > From your description, I think the traditional solution is also a good solution. If anything you will likely underutilize your resources. > > If necessary, just use a container then workout the infrastructure to route the requests, this will need some service discovery or a manual management of the route map (eg: nginx config). But the benefit of using this instead of a raw deployment is that a lot of the issues listed have solutions that have been tested. > > From: Lloyd R. Prentice > Sent: Tuesday, 14 May 2019 11:59 PM > To: Chinedu Okonkwo > Cc: Erlang Questions > Subject: Re: [erlang-questions] Multiple BEAM nodes on one Linux node ? a thought experiment > > Hi Chinedu, > > So operationally, would one install a release for each user in separate directories? > > My musings, uninformed by experience, have progressed more or less along this line: > > ? Data loss is totally unacceptable to the users I have in mind. > > ? There could be many users, each with his/her own corpus of data; no intersection. > > ? Traffic per user would be quite low. > > ? Data corpus per user would be fairly small. > > ? Users come and go. When they go, they want to take their data. Some may want to return and pickup where they left off. > > ? The traditional solution would be a capacious, maybe even distributed, database behind a single, well maybe load balanced, front end. > > ? But this means that there could potentially be an increasing volume of ?dead,? e.g. unused data, or one would need a way to archive data when a user leaves. In this second case, archiving and restoring data over many users could tie up a great deal of db?s bandwidth. > > ? Fanciful solution I: Give each user his/her own independent website. > > ? Linux containers might make this possible. > > ? Transactions are not an issue. > > ? A small Mnesia db or even dets db per user would suffice. > > ? Linux containers could be deployed over multiple hardware or VPS nodes, lowering hardware failure risk and making it relatively easy to scale from just a few users to many many. > > ? LXD provides tools that would make it relatively easy to induct new users and replicate user sites. > > ? But would it be economically feasible? > > ? Fanciful solution II: Multiple BEAM nodes per Linux node. > > ? Hmmm... might have to functionally replicate tools that LXD already provides. > > ? But it might be more resource efficient. > > ? Can it even work? > > And so, my head spins for lack of experience. > > And so, I?d much appreciate insight and guidance from experienced hands. > > All the best, > > Lloyd > > Sent from my iPad > > On May 14, 2019, at 5:36 PM, Chinedu Okonkwo wrote: > > That is pretty much what erlang release is. > > I think its one of the reason docker/containers didn't catch on in the erlang community. The major problem you may face running it especially in distributed erlang mode may be name collusion in empd > > On Tue, May 14, 2019 at 9:13 PM Lloyd R. Prentice wrote: > Hello, > > My Mickey-the-Dunce ignorance and curiosity has led me to explore Linux containers. Very cool. Then, a recent conversation with Oliver Korpilla tweaked my wonder nerve: > > Is it possible/practical to run multiple BEAM nodes on a single Linux node? > > Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services? each for a different client. > > Has anyone ever done anything along this line? > > Best wishes, > > LRP > > Sent from my iPad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Wed May 15 10:20:23 2019 From: otp@REDACTED (Erlang/OTP) Date: Wed, 15 May 2019 10:20:23 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8.1 Released Message-ID: <20190515082023.GA58988@erix.ericsson.se> Patch Package: OTP 21.3.8.1 Git Tag: OTP-21.3.8.1 Date: 2019-05-15 Trouble Report Id: OTP-15813, OTP-15819, OTP-15823 Seq num: ERL-934, ERL-938, ERL-943, ERL-944 System: OTP Release: 21 Application: erts-10.3.5.1, ssl-9.2.3.1, tools-3.1.0.1 Predecessor: OTP 21.3.8 Check out the git tag OTP-21.3.8.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. --------------------------------------------------------------------- --- erts-10.3.5.1 --------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.5.1 application *cannot* be applied independently of other applications on an arbitrary OTP 21 installation. On a full OTP 21 installation, also the following runtime dependencies have to be satisfied: -- kernel-6.1 (first satisfied in OTP 21.1) -- sasl-3.3 (first satisfied in OTP 21.2) --- Fixed Bugs and Malfunctions --- OTP-15819 Application(s): erts Related Id(s): ERL-944 Fixed a buffer overflow when binary_to_existing_atom/2 and list_to_existing_atom/2 was used with the latin1 encoding. Full runtime dependencies of erts-10.3.5.1: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- ssl-9.2.3.1 ----------------------------------------------------- --------------------------------------------------------------------- The ssl-9.2.3.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15823 Application(s): ssl Related Id(s): ERL-934, ERL-938 Correct solution for retaining tcp flow control OTP-15802 (ERL-934) as to not break ssl:recv as reported in (ERL-938) Full runtime dependencies of ssl-9.2.3.1: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --- tools-3.1.0.1 --------------------------------------------------- --------------------------------------------------------------------- The tools-3.1.0.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15813 Application(s): tools Related Id(s): ERL-943 cover would fail to start if two processes tried to start it at the exact same time. Full runtime dependencies of tools-3.1.0.1: compiler-5.0, erts-9.1, kernel-5.4, runtime_tools-1.8.14, stdlib-3.4 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From roger@REDACTED Wed May 15 10:40:35 2019 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 15 May 2019 09:40:35 +0100 Subject: [erlang-questions] =?utf-8?q?Multiple_BEAM_nodes_on_one_Linux_nod?= =?utf-8?q?e_=E2=80=94_a_thought_experiment?= In-Reply-To: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> References: <2B652320-E233-4212-9154-0B56CF0EAE66@writersglen.com> Message-ID: On Tue, 14 May 2019 at 22:12, Lloyd R. Prentice wrote: > Is it possible/practical to run multiple BEAM nodes on a single Linux node? Yes. We do this. IoT devices connect to one node; their backend agents/actors run in a different node on the same machine, connected by Erlang distribution. We do this for isolation (partly because there's a large and complex NIF in the second node), plus for historical reasons -- which we periodically revisit and decide "nah, not worth the effort". > Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services? each for a different client. However: I wouldn't bother doing this. It won't scale beyond, say, a few dozen nodes -- depending on the size of the host -- and you'd be wasting a bunch of capacity on the host (remember that Unix process overhead is several orders of magnitude more than Erlang process overhead, and both are dwarfed by container overhead). You'd be better served by looking at making a single node multitenant. You could do this by using a separate mnesia table per client, or use prefixed keys within whatever tables you're planning to use. Or use a relational model, where each entity has a related owner. From tom@REDACTED Wed May 15 10:54:40 2019 From: tom@REDACTED (Thomas Cioppettini) Date: Wed, 15 May 2019 04:54:40 -0400 Subject: [erlang-questions] OTP 22.0 doc_man SHA256 mismatch? Message-ID: So I was going about updating the erlang homebrew formula and am running into a weird issue. Here's what I've done so far. I've download the following file: https://www.erlang.org/download/otp_doc_man_22.0.tar.gz I ran this command on that file to get the sha256 checksum for homebrew $: shasum -a 256 otp_doc_man_22.0.tar.gz => e384ba02133aabc3ebac421f4dbd46893540e746c6a7ac5e90c4d2be850d08c6 I've updated homebrew with that sha, but with the upgrade I'm getting a ChecksumMismatchError which I think is weird. After taking a look at the file homebrew is downloading it's size matches 1.3M so that makes sense. So I then went to check the original tar.gz I've downloaded and that comes in at a whopping 7.1M. Does anyone have a clue as to why these files might be different? I know that they could be different for nefarious reasons, but I wanted a sanity check before I went to sabotage as the reason the files are different. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prakash.parmar@REDACTED Wed May 15 11:34:56 2019 From: prakash.parmar@REDACTED (Prakash Parmar) Date: Wed, 15 May 2019 09:34:56 +0000 Subject: [erlang-questions] Performance bottleneck of Custom Behavior Message-ID: Hello All, We have a custom behavior based on gen_server with single callback function. After profiling the code we found that invoking a callback function is taking consider amount of time. The argument of callback is record of 50 elements. Did this huge record is a problem ? What are the VM parameters we supposed to fine tune ? Like increasing heap size to avoid GC, etc ... Regards, Prakash -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth@REDACTED Wed May 15 12:06:13 2019 From: kenneth@REDACTED (Kenneth Lundin) Date: Wed, 15 May 2019 12:06:13 +0200 Subject: [erlang-questions] OTP 22.0 doc_man SHA256 mismatch? In-Reply-To: References: Message-ID: The file on the server is 1.3 Mbytes but decompressed with "gunzip" I get 7065600 bytes which matches the 7.1M you mention. I think your browser or something is uncompressing the file automatically. The checksum you get is what I get when running on the 7.1M gunzipped file $: shasum -a 256 otp_doc_man_22.0.tar /Regards Kenneth , Erlang/OTP Ericsson On Wed, May 15, 2019 at 11:32 AM Thomas Cioppettini wrote: > So I was going about updating the erlang homebrew formula and am running > into a weird issue. Here's what I've done so far. > > I've download the following file: > https://www.erlang.org/download/otp_doc_man_22.0.tar.gz > > I ran this command on that file to get the sha256 checksum for homebrew > > $: shasum -a 256 otp_doc_man_22.0.tar.gz > => e384ba02133aabc3ebac421f4dbd46893540e746c6a7ac5e90c4d2be850d08c6 > > I've updated homebrew with that sha, but with the upgrade I'm getting > a ChecksumMismatchError which I think is weird. After taking a look at the > file homebrew is downloading it's size matches 1.3M so that makes sense. So > I then went to check the original tar.gz I've downloaded and that comes in > at a whopping 7.1M. Does anyone have a clue as to why these files might be > different? > > I know that they could be different for nefarious reasons, but I wanted a > sanity check before I went to sabotage as the reason the files are > different. > > > _______________________________________________ > 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 Wed May 15 12:13:29 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 15 May 2019 12:13:29 +0200 Subject: [erlang-questions] Performance bottleneck of Custom Behavior In-Reply-To: References: Message-ID: On Wed, May 15, 2019 at 11:35 AM Prakash Parmar wrote: > > Hello All, > > We have a custom behavior based on gen_server with single callback function. After profiling the code we found that invoking a callback function is taking consider amount of time. The argument of callback is record of 50 elements. Did this huge record is a problem ? If this 50-element record is passed across process boundaries, then yes you may see some performance hit. As long as the value is simply passed around in a single process it shouldn't cause any issue. From okaprinarjaya@REDACTED Thu May 16 09:43:39 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Thu, 16 May 2019 14:43:39 +0700 Subject: [erlang-questions] Performance bottleneck of Custom Behavior In-Reply-To: References: Message-ID: Hi, @Prakash Parmar, @Mikael Petterson I don't understand did you mean like these? something(A, B, C, D, E, ....... Param50) -> ok. or something({abc}, {def}, {ghi}, ........ {param50} ) -> ok. Please enlighten me Thank you Pada tanggal Rab, 15 Mei 2019 pukul 17.13 Mikael Pettersson < mikpelinux@REDACTED> menulis: > On Wed, May 15, 2019 at 11:35 AM Prakash Parmar > wrote: > > > > Hello All, > > > > We have a custom behavior based on gen_server with single callback > function. After profiling the code we found that invoking a callback > function is taking consider amount of time. The argument of callback is > record of 50 elements. Did this huge record is a problem ? > > If this 50-element record is passed across process boundaries, then > yes you may see some performance hit. As long as the value is simply > passed around in a single process it shouldn't cause any issue. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakabac@REDACTED Thu May 16 12:41:29 2019 From: jakabac@REDACTED (Jaka Bac) Date: Thu, 16 May 2019 12:41:29 +0200 Subject: [erlang-questions] Compiling OTP on Windows In-Reply-To: References: Message-ID: The windows build process&setup is not "magic" at all.... In fact it is actually possible to build Erlang/OTP with MSVC 2019 My build process (instructions not exact) looked like this: 1. Install MSVC 2019 2. Install MSYS2 and configure it so the msys shell inherits the Windows environment (PATH) when started. Also install all the "Linux" prereqs (GCC,...) 3. Download and build OpenSSL (follow OpenSSL build instructions, I used 1.1.1b version to get all possible ciphers, hashes,...) 4. Download and build wxWidgets (put wxWidgets in /opt/local/pgm and build the static libs there (instructions taken from OTP build guide for WIN, wxWidgets 3.0.4 is also fine): C:\...\> cd \wxMSW-3.0.3\build\msw C:\...\> nmake TARGET_CPU=amd64 BUILD=release SHARED=0 DIR_SUFFIX_CPU= -f makefile.vc 5. Apply this patch: diff --git a/erts/etc/win32/msys_tools/vc/cc.sh b/erts/etc/win32/msys_tools/vc/cc.sh index 2b0482e876..99db719c38 100644 --- a/erts/etc/win32/msys_tools/vc/cc.sh +++ b/erts/etc/win32/msys_tools/vc/cc.sh @@ -242,7 +242,10 @@ for x in $SOURCES; do if [ $PREPROCESSING = true ]; then output_flag="-E" else + output_flag="-FS -c -Fo`cmd //C echo ${output_filename}`" + output_flag=`echo $output_flag | sed -e 's/\\//\\\\\\\\/g'` + #echo "PATCHED OUTPUT: " $output_flag fi params="$COMMON_CFLAGS $MD $DEBUG_FLAGS $OPTIMIZE_FLAGS \ $CMD ${output_flag} $MPATH" The cc.sh makes cl.exe look like gcc to the OTP build environment. It does fiddling with the paths to translate them from MSYS style to native paths. But it seems that MSVC 2019 does not like absolute paths with / insted of \ (Relative paths work fine with /) 5. Follow the WIN build instructions for OTP (tell configure where your OpenSSL lives): $ eval `./otp_build env_win32 x64` $ ./otp_build autoconf $ ./otp_build configure --with-ssl=/x/path/to/openssl #you might want to tell it where to find javac also if you want jinterface Even if configure does not complainabout OpenSSL it seems that everythig is still not as the build environment expects. I had to copy libcrypto_static.lib and libssl_static.lib to c_src folder lib\crypto\c_src while renaming them to crypto.lib and ssl.lib. Also It seems that I built OpenSSL with newtorking support since the OTP build died while building crypto app with unresolved winsock symbols. To fix it I added LDFLAGS += -dll Ws2_32.Lib to otp\lib\crypto\c_src\win32\Makefile (please keep in mind that this file is probably generated during the build process so this is a dirty hack, I did not feel like digging deeper into the build scripts, makefiles etc...) $ ./otp_build boot -a $ ./otp_build release -a Building the installer expects a pretty ancient NSIS installation. I just removed the version checks in the installer makefile to go through that, but you really don't need the installer... After ./otp_build release -a completes you will find everything you need in otp\release\win32. This is more or less what the installer will pack. You can just copy that folder to wherever you want your build to live and run install.exe in that folder as the last step (this is also done by the windows installer) It will create bin folder and put all the "public" exes there, set up an erl.ini and also copy the boot scripts into bin. After that you are good to go! I did not bother building the docs, but feel free to try that... I confirmed that wx application is working by running observer and also did limited testing of the crypto app. If you get stuck feel free to contact me Cheers, Jaka On Tue, 30 Apr 2019 at 17:50, Andre Nathan wrote: > > On 4/30/19 12:36 PM, Dmytro Lytovchenko wrote: > > From what I know the building instructions are pure magic involving > > MinGW and Visual Studio, and it is dangerous to go alone. > > Take this https://visualstudio.microsoft.com/vs/older-downloads/ > > Yeah, I've found that, but the VS 2013 link leads to a page that says no > downloads are available. > > Thanks, > Andre > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dinislam.Salikhov@REDACTED Thu May 16 18:08:28 2019 From: Dinislam.Salikhov@REDACTED (Salikhov Dinislam) Date: Thu, 16 May 2019 19:08:28 +0300 Subject: [erlang-questions] Non-typed errors in catch Message-ID: Hello, I have the following module: -module(exception). -export([ ??? foo/1 ]). foo(Any) -> ??? try Any + 1 of ??? ??? Any -> ok ??? catch ??? ??? Error -> {not_typed, Error};????????? ? ? ?? % warn? ??? ??? any:Error -> {any_error, Error};?? ? ? ? ? % warn? ??? ??? Type:Error -> {typed_error, {Type, Error}} ??? end. Compiler doesn't complain about the marked lines. Neither does dialyzer. Is there any rationale for such behaviour? Or is it a bug? P.S. I use Erlang/OTP 20 [erts-9.3.2]. Regards, Dinislam Salikhov -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrukoff@REDACTED Thu May 16 19:38:41 2019 From: jkrukoff@REDACTED (John Krukoff) Date: Thu, 16 May 2019 17:38:41 +0000 Subject: [erlang-questions] Non-typed errors in catch In-Reply-To: References: Message-ID: I?ve no insight into why the set of valid exception classes isn?t restricted to the 3 the run time can actually create, but can at least point to the explanation of why `catch Error ->` is valid: > It is allowed to omit Class and Stacktrace. An omitted Class is shorthand for throw: from: http://erlang.org/doc/reference_manual/expressions.html#try And illustrated by: ``` > try throw(broke) catch Error -> {throw, Error} end. {throw,broke} ``` -- John Krukoff jkrukoff@REDACTED From: erlang-questions-bounces@REDACTED On Behalf Of Salikhov Dinislam Sent: Thursday, May 16, 2019 10:08 To: Erlang/OTP discussions Subject: [erlang-questions] Non-typed errors in catch Hello, I have the following module: -module(exception). -export([ foo/1 ]). foo(Any) -> try Any + 1 of Any -> ok catch Error -> {not_typed, Error}; % warn? any:Error -> {any_error, Error}; % warn? Type:Error -> {typed_error, {Type, Error}} end. Compiler doesn't complain about the marked lines. Neither does dialyzer. Is there any rationale for such behaviour? Or is it a bug? P.S. I use Erlang/OTP 20 [erts-9.3.2]. Regards, Dinislam Salikhov -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6290 bytes Desc: not available URL: From max.lapshin@REDACTED Sat May 18 11:46:05 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 18 May 2019 12:46:05 +0300 Subject: [erlang-questions] Erlang/OTP 22.0 has been released In-Reply-To: <1557839551.31047.74.camel@ericsson.com> References: <1557839551.31047.74.camel@ericsson.com> Message-ID: Great job, thanks! Just filed a small bug, cannot compile file that was compiling in old versions. Sorry for non-checking it before release =( -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sat May 18 11:53:49 2019 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 18 May 2019 11:53:49 +0200 Subject: [erlang-questions] [ANN] geas 2.4.5 (Erlang 22.0) Message-ID: Hi Geas 2.4.5 has been released ! Geas is a tool detecting the runnable official Erlang release window for your project. Geas will tell you also : - what are the offending functions in the beam/source files that reduce the available window. - if some beam files are compiled native. - the installed patches and recommend patches that should be installed depending your code. Geas is available as a module, erlang.mk and rebar 2/3 plugins. Changelog : - Update for Erlang 22.0 detection and database https://github.com/crownedgrouse/geas https://github.com/crownedgrouse/geas/releases/tag/2.4.5 Change between 21.3 and 22.0 : https://raw.githubusercontent.com/crownedgrouse/geas_devel/master/doc/reldiffs/yaml/21.3~22.0 Cheers ! Eric From frank.muller.erl@REDACTED Sun May 19 23:24:14 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Sun, 19 May 2019 23:24:14 +0200 Subject: [erlang-questions] Erlang 22.0 failed to compile on macOS HighSierra 10.13.6 Message-ID: Hi everyone, $ export KERL_BUILD_BACKEND=git $ kerl build git https://github.com/erlang/otp.gitOTP-22.0 22.0 $ tail -f /Users/frank/.kerl/builds/22.0/otp_build_git.log [...] Undefined symbols for architecture x86_64: "_erts_bind_to_cpu", referenced from: _erts_sched_check_cpu_bind in erl_cpu_topology.o _erts_init_scheduler_bind_type_string in erl_cpu_topology.o _erts_bind_schedulers in erl_cpu_topology.o "_erts_cbprintf", referenced from: _erl_crash_dump_v in break.o _erts_print_nif_taints in erl_nif.o "_erts_cpu_info_create", referenced from: _erts_pre_early_init_cpu_topology in erl_cpu_topology.o "_erts_cpu_info_update", referenced from: _erts_update_cpu_info in erl_cpu_topology.o "_erts_dsprintf", referenced from: _handle_error in beam_emu.o _erts_make_stub_module in beam_load.o _load_printf in beam_load.o $ clang --version Apple LLVM version 10.0.0 (clang-1000.10.44.4) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Anyone's facing the same issue? /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From by@REDACTED Mon May 20 05:16:52 2019 From: by@REDACTED (by) Date: Mon, 20 May 2019 11:16:52 +0800 Subject: [erlang-questions] What is the unit for max_frame_size(WebSocket) on Cowboy? Message-ID: Hello List, As stated in the subject, anyone knew the unit for max_frame_size(WebSocket) on Cowboy? For convention, this should be ?byte". Just want to make sure. I checked with https://ninenines.eu/docs/en/cowboy/2.6/manual/cowboy_websocket/ but no explicit word specify this. Best Regards, Yao -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon May 20 09:17:46 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 20 May 2019 09:17:46 +0200 Subject: [erlang-questions] What is the unit for max_frame_size(WebSocket) on Cowboy? In-Reply-To: References: Message-ID: <33be9369-10b1-1be3-fe48-7cecbed121c8@ninenines.eu> Yes bytes. Every data sizes in Cowboy are bytes. Please send a patch to the docs. https://github.com/ninenines/cowboy/blob/master/doc/src/manual/cowboy_websocket.asciidoc On 20/05/2019 05:16, by wrote: > Hello List, > > As stated in the subject, anyone knew the unit > for?max_frame_size(WebSocket) on Cowboy? > > For convention, this should be ?byte". Just want to make sure. > I checked with > https://ninenines.eu/docs/en/cowboy/2.6/manual/cowboy_websocket/?but no > explicit word specify this. > > Best Regards, > Yao > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin https://ninenines.eu From by@REDACTED Mon May 20 09:40:16 2019 From: by@REDACTED (by) Date: Mon, 20 May 2019 15:40:16 +0800 Subject: [erlang-questions] What is the unit for max_frame_size(WebSocket) on Cowboy? In-Reply-To: <33be9369-10b1-1be3-fe48-7cecbed121c8@ninenines.eu> References: <33be9369-10b1-1be3-fe48-7cecbed121c8@ninenines.eu> Message-ID: I created a pull request for it: https://github.com/ninenines/cowboy/pull/1377 > ? 2019?5?20??15:17?Lo?c Hoguin ??? > > Yes bytes. Every data sizes in Cowboy are bytes. Please send a patch to the docs. > > https://github.com/ninenines/cowboy/blob/master/doc/src/manual/cowboy_websocket.asciidoc > > On 20/05/2019 05:16, by wrote: >> Hello List, >> As stated in the subject, anyone knew the unit for max_frame_size(WebSocket) on Cowboy? >> For convention, this should be ?byte". Just want to make sure. >> I checked with https://ninenines.eu/docs/en/cowboy/2.6/manual/cowboy_websocket/ but no explicit word specify this. >> Best Regards, >> Yao >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- > Lo?c Hoguin > https://ninenines.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon May 20 11:03:18 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 20 May 2019 12:03:18 +0300 Subject: [erlang-questions] Erlang 22.0 failed to compile on macOS HighSierra 10.13.6 In-Reply-To: References: Message-ID: macbook-pro:flussonic max$ clang --version Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Compiled 22.0 without any issues: ./configure --prefix=/usr/local/Cellar/erlang/22.0 --enable-threads --enable-dirty-schedulers --enable-smp-support --enable-kernel-poll --enable-m64-build --with-dynamic-trace=dtrace --without-javac --with-wx --with-microstate-accounting=extra --enable-hipe --enable-lock-counter --with-ssl=/usr/local/opt/openssl --without-diameter --without-eldap --without-jinterface --without-megaco --without-odbc --with-wx-prefix=/usr/local/opt/wxmac almost no issues, because I cannot make wx work. I haven't seen it working for several years on my macbook =( -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Mon May 20 11:44:07 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 20 May 2019 11:44:07 +0200 Subject: [erlang-questions] Performance bottleneck of Custom Behavior In-Reply-To: References: Message-ID: <20190520094407.GA24814@erix.ericsson.se> On Wed, May 15, 2019 at 12:13:29PM +0200, Mikael Pettersson wrote: > On Wed, May 15, 2019 at 11:35 AM Prakash Parmar > wrote: > > > > Hello All, > > > > We have a custom behavior based on gen_server with single callback function. After profiling the code we found that invoking a callback function is taking consider amount of time. The argument of callback is record of 50 elements. Did this huge record is a problem ? > > If this 50-element record is passed across process boundaries, then > yes you may see some performance hit. As long as the value is simply > passed around in a single process it shouldn't cause any issue. And when you change a field in a record a new copy is created, which for a 50 element record can hurt performance both by the copying time and by the increased load on the garbage collection. We usually try to break down such a record into a tree structure of records, so that an update does not require copying all elements. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From oltarasenko@REDACTED Mon May 20 11:51:07 2019 From: oltarasenko@REDACTED (Oleg Tarasenko) Date: Mon, 20 May 2019 12:51:07 +0300 Subject: [erlang-questions] Compiling OTP on Windows In-Reply-To: References: Message-ID: Hi Jaka, I am trying to follow your steps in order to compile it on Windows 10 (using cygwin instead of msys2, but on msys2 I seem to get the same). For now, getting errors :(. $ ./otp_build configure > Copying static configure cache > /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache.static > to > /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache > /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/configure > --build=x86_64-unknown-cygwin build_alias=win32 --host=win32 --target=win32 > --disable-dynamic-ssl-lib > --cache-file=/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache > CC=cc\.sh CXX=cc\.sh RANLIB=true AR=ar\.sh > WARNING: Only using config cache file > '/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache' > as static cache > === Running configure in > /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts === > ./configure '--build=x86_64-unknown-cygwin' 'build_alias=win32' > '--host=win32' '--target=win32' '--disable-dynamic-ssl-lib' 'CC=cc.sh' > 'CXX=cc.sh' 'RANLIB=true' 'AR=ar.sh' --disable-option-checking > --cache-file=./local.static.config.cache > --srcdir="/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts" > configure: loading cache ./local.static.config.cache > checking for win32-gcc... (cached) cc.sh > checking whether the C compiler works... no > configure: error: in `/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts': > configure: error: C compiler cannot create executables > See `config.log' for more details > ERROR: /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/configure > failed! > ./configure: line 343: kill: (-2670) - No such process I want to ask if you can share the contents of "cc.sh". Also maybe you could advise what might be missing. Oleg On Thu, May 16, 2019 at 1:43 PM Jaka Bac wrote: > The windows build process&setup is not "magic" at all.... > > In fact it is actually possible to build Erlang/OTP with MSVC 2019 > My build process (instructions not exact) looked like this: > 1. Install MSVC 2019 > 2. Install MSYS2 and configure it so the msys shell inherits the Windows > environment (PATH) when started. Also install all the "Linux" prereqs > (GCC,...) > 3. Download and build OpenSSL (follow OpenSSL build instructions, I used > 1.1.1b version to get all possible ciphers, hashes,...) > 4. Download and build wxWidgets (put wxWidgets in /opt/local/pgm and build > the static libs there (instructions taken from OTP build guide for WIN, > wxWidgets 3.0.4 is also fine): > > C:\...\> cd \wxMSW-3.0.3\build\msw > C:\...\> nmake TARGET_CPU=amd64 BUILD=release SHARED=0 DIR_SUFFIX_CPU= -f > makefile.vc > > > 5. Apply this patch: > diff --git a/erts/etc/win32/msys_tools/vc/cc.sh > b/erts/etc/win32/msys_tools/vc/cc.sh > index 2b0482e876..99db719c38 100644 > --- a/erts/etc/win32/msys_tools/vc/cc.sh > +++ b/erts/etc/win32/msys_tools/vc/cc.sh > @@ -242,7 +242,10 @@ for x in $SOURCES; do > if [ $PREPROCESSING = true ]; then > output_flag="-E" > else > + > output_flag="-FS -c -Fo`cmd //C echo ${output_filename}`" > + output_flag=`echo $output_flag | sed -e 's/\\//\\\\\\\\/g'` > + #echo "PATCHED OUTPUT: " $output_flag > fi > params="$COMMON_CFLAGS $MD $DEBUG_FLAGS $OPTIMIZE_FLAGS \ > $CMD ${output_flag} $MPATH" > > The cc.sh makes cl.exe look like gcc to the OTP build environment. It does > fiddling with the paths to translate them from MSYS style to native paths. > But it seems that MSVC 2019 does not like absolute paths with / insted of \ > (Relative paths work fine with /) > > 5. Follow the WIN build instructions for OTP (tell configure where your > OpenSSL lives): > > $ eval `./otp_build env_win32 x64` > $ ./otp_build autoconf > $ ./otp_build configure --with-ssl=/x/path/to/openssl #you might want to > tell it where to find javac also if you want jinterface > > Even if configure does not complainabout OpenSSL it seems that everythig > is still not as the build environment expects. I had to copy > libcrypto_static.lib and libssl_static.lib to c_src folder lib\crypto\c_src > while renaming them to crypto.lib and ssl.lib. > Also It seems that I built OpenSSL with newtorking support since the OTP > build died while building crypto app with unresolved winsock symbols. To > fix it I added > LDFLAGS += -dll Ws2_32.Lib > to otp\lib\crypto\c_src\win32\Makefile (please keep in mind that this file > is probably generated during the build process so this is a dirty hack, I > did not feel like digging deeper into the build scripts, makefiles etc...) > > $ ./otp_build boot -a > $ ./otp_build release -a > > Building the installer expects a pretty ancient NSIS installation. I just > removed the version checks in the installer makefile to go through that, > but you really don't need the installer... > > After ./otp_build release -a completes you will find everything you need > in otp\release\win32. This is more or less what the installer will pack. > > You can just copy that folder to wherever you want your build to live and > run install.exe in that folder as the last step (this is also done by the > windows installer) > It will create bin folder and put all the "public" exes there, set up an > erl.ini and also copy the boot scripts into bin. > > After that you are good to go! > I did not bother building the docs, but feel free to try that... > > I confirmed that wx application is working by running observer and also > did limited testing of the crypto app. > > If you get stuck feel free to contact me > Cheers, > Jaka > > On Tue, 30 Apr 2019 at 17:50, Andre Nathan wrote: > > > > On 4/30/19 12:36 PM, Dmytro Lytovchenko wrote: > > > From what I know the building instructions are pure magic involving > > > MinGW and Visual Studio, and it is dangerous to go alone. > > > Take this https://visualstudio.microsoft.com/vs/older-downloads/ > > > > Yeah, I've found that, but the VS 2013 link leads to a page that says no > > downloads are available. > > > > Thanks, > > Andre > > _______________________________________________ > > 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 otp@REDACTED Mon May 20 13:24:01 2019 From: otp@REDACTED (Erlang/OTP) Date: Mon, 20 May 2019 13:24:01 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8.2 Released Message-ID: <20190520112400.GA54375@erix.ericsson.se> Patch Package: OTP 21.3.8.2 Git Tag: OTP-21.3.8.2 Date: 2019-05-20 Trouble Report Id: OTP-15826 Seq num: System: OTP Release: 21 Application: xmerl-1.3.20.1 Predecessor: OTP 21.3.8.1 Check out the git tag OTP-21.3.8.2, 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. --------------------------------------------------------------------- --- xmerl-1.3.20.1 -------------------------------------------------- --------------------------------------------------------------------- The xmerl-1.3.20.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15826 Application(s): xmerl xmerl_sax_parser crashed during charset detection when the xml declarations attribute values was missing the closing quotation (' or "). Full runtime dependencies of xmerl-1.3.20.1: erts-6.0, kernel-3.0, stdlib-2.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From jakabac@REDACTED Mon May 20 12:47:33 2019 From: jakabac@REDACTED (Jaka Bac) Date: Mon, 20 May 2019 12:47:33 +0200 Subject: [erlang-questions] Compiling OTP on Windows In-Reply-To: References: Message-ID: Hi Oleg, I just noticed that I forgot to mention that before running msys shell (which should be configured to inherit the windows environment variables), that you need to run the vcvars64.bat so you have the paths set up for running cl.exe You can find a shortcut for that in the start menu under "Visual Studio 2019" folder (previous VS versions have the same). Probably this is causing your error. Before starting the build you make sure that the msys/cygwin shell can actually run cl.exe (just try to run cl) Otherwise I did not test this with cygwin. But it seems that cygwin has its own cc.sh in erts\etc\win32\cygwin_tools\vc I will send cc.sh to you in a separate email (to not spam the list), the only change that I did is adding this line: output_flag=`echo $output_flag | sed -e 's/\\//\\\\\\\\/g'` after output_flag="-FS -c -Fo`cmd //C echo ${output_filename}`" Jaka On Mon, 20 May 2019 at 11:51, Oleg Tarasenko wrote: > Hi Jaka, > > I am trying to follow your steps in order to compile it on Windows 10 > (using cygwin instead of msys2, but on msys2 I seem to get the same). For > now, getting errors :(. > > $ ./otp_build configure >> Copying static configure cache >> /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache.static >> to >> /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache >> /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/configure >> --build=x86_64-unknown-cygwin build_alias=win32 --host=win32 --target=win32 >> --disable-dynamic-ssl-lib >> --cache-file=/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache >> CC=cc\.sh CXX=cc\.sh RANLIB=true AR=ar\.sh >> WARNING: Only using config cache file >> '/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/autoconf/win32.config.cache' >> as static cache >> === Running configure in >> /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts === >> ./configure '--build=x86_64-unknown-cygwin' 'build_alias=win32' >> '--host=win32' '--target=win32' '--disable-dynamic-ssl-lib' 'CC=cc.sh' >> 'CXX=cc.sh' 'RANLIB=true' 'AR=ar.sh' --disable-option-checking >> --cache-file=./local.static.config.cache >> --srcdir="/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts" >> configure: loading cache ./local.static.config.cache >> checking for win32-gcc... (cached) cc.sh >> checking whether the C compiler works... no >> configure: error: in >> `/cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts': >> configure: error: C compiler cannot create executables >> See `config.log' for more details >> ERROR: /cygdrive/c/Users/oltar/Downloads/otp_src_22.0/erts/configure >> failed! >> ./configure: line 343: kill: (-2670) - No such process > > > I want to ask if you can share the contents of "cc.sh". Also maybe you > could advise what might be missing. > Oleg > > On Thu, May 16, 2019 at 1:43 PM Jaka Bac wrote: > >> The windows build process&setup is not "magic" at all.... >> >> In fact it is actually possible to build Erlang/OTP with MSVC 2019 >> My build process (instructions not exact) looked like this: >> 1. Install MSVC 2019 >> 2. Install MSYS2 and configure it so the msys shell inherits the Windows >> environment (PATH) when started. Also install all the "Linux" prereqs >> (GCC,...) >> 3. Download and build OpenSSL (follow OpenSSL build instructions, I used >> 1.1.1b version to get all possible ciphers, hashes,...) >> 4. Download and build wxWidgets (put wxWidgets in /opt/local/pgm and >> build the static libs there (instructions taken from OTP build guide for >> WIN, wxWidgets 3.0.4 is also fine): >> >> C:\...\> cd \wxMSW-3.0.3\build\msw >> C:\...\> nmake TARGET_CPU=amd64 BUILD=release SHARED=0 DIR_SUFFIX_CPU= -f >> makefile.vc >> >> >> 5. Apply this patch: >> diff --git a/erts/etc/win32/msys_tools/vc/cc.sh >> b/erts/etc/win32/msys_tools/vc/cc.sh >> index 2b0482e876..99db719c38 100644 >> --- a/erts/etc/win32/msys_tools/vc/cc.sh >> +++ b/erts/etc/win32/msys_tools/vc/cc.sh >> @@ -242,7 +242,10 @@ for x in $SOURCES; do >> if [ $PREPROCESSING = true ]; then >> output_flag="-E" >> else >> + >> output_flag="-FS -c -Fo`cmd //C echo ${output_filename}`" >> + output_flag=`echo $output_flag | sed -e 's/\\//\\\\\\\\/g'` >> + #echo "PATCHED OUTPUT: " $output_flag >> fi >> params="$COMMON_CFLAGS $MD $DEBUG_FLAGS $OPTIMIZE_FLAGS \ >> $CMD ${output_flag} $MPATH" >> >> The cc.sh makes cl.exe look like gcc to the OTP build environment. It >> does fiddling with the paths to translate them from MSYS style to native >> paths. But it seems that MSVC 2019 does not like absolute paths with / >> insted of \ (Relative paths work fine with /) >> >> 5. Follow the WIN build instructions for OTP (tell configure where your >> OpenSSL lives): >> >> $ eval `./otp_build env_win32 x64` >> $ ./otp_build autoconf >> $ ./otp_build configure --with-ssl=/x/path/to/openssl #you might want to >> tell it where to find javac also if you want jinterface >> >> Even if configure does not complainabout OpenSSL it seems that everythig >> is still not as the build environment expects. I had to copy >> libcrypto_static.lib and libssl_static.lib to c_src folder lib\crypto\c_src >> while renaming them to crypto.lib and ssl.lib. >> Also It seems that I built OpenSSL with newtorking support since the OTP >> build died while building crypto app with unresolved winsock symbols. To >> fix it I added >> LDFLAGS += -dll Ws2_32.Lib >> to otp\lib\crypto\c_src\win32\Makefile (please keep in mind that this >> file is probably generated during the build process so this is a dirty >> hack, I did not feel like digging deeper into the build scripts, makefiles >> etc...) >> >> $ ./otp_build boot -a >> $ ./otp_build release -a >> >> Building the installer expects a pretty ancient NSIS installation. I just >> removed the version checks in the installer makefile to go through that, >> but you really don't need the installer... >> >> After ./otp_build release -a completes you will find everything you need >> in otp\release\win32. This is more or less what the installer will pack. >> >> You can just copy that folder to wherever you want your build to live and >> run install.exe in that folder as the last step (this is also done by the >> windows installer) >> It will create bin folder and put all the "public" exes there, set up an >> erl.ini and also copy the boot scripts into bin. >> >> After that you are good to go! >> I did not bother building the docs, but feel free to try that... >> >> I confirmed that wx application is working by running observer and also >> did limited testing of the crypto app. >> >> If you get stuck feel free to contact me >> Cheers, >> Jaka >> >> On Tue, 30 Apr 2019 at 17:50, Andre Nathan wrote: >> > >> > On 4/30/19 12:36 PM, Dmytro Lytovchenko wrote: >> > > From what I know the building instructions are pure magic involving >> > > MinGW and Visual Studio, and it is dangerous to go alone. >> > > Take this https://visualstudio.microsoft.com/vs/older-downloads/ >> > >> > Yeah, I've found that, but the VS 2013 link leads to a page that says no >> > downloads are available. >> > >> > Thanks, >> > Andre >> > _______________________________________________ >> > 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 frank.muller.erl@REDACTED Mon May 20 13:47:27 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Mon, 20 May 2019 13:47:27 +0200 Subject: [erlang-questions] Erlang 22.0 failed to compile on macOS HighSierra 10.13.6 In-Reply-To: References: Message-ID: Max Are you under Mojave, or HighSierra? /Frank macbook-pro:flussonic max$ clang --version > Apple LLVM version 10.0.0 (clang-1000.11.45.5) > Target: x86_64-apple-darwin18.2.0 > Thread model: posix > InstalledDir: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > > Compiled 22.0 without any issues: > > ./configure --prefix=/usr/local/Cellar/erlang/22.0 --enable-threads > --enable-dirty-schedulers --enable-smp-support --enable-kernel-poll > --enable-m64-build --with-dynamic-trace=dtrace --without-javac --with-wx > --with-microstate-accounting=extra --enable-hipe --enable-lock-counter > --with-ssl=/usr/local/opt/openssl --without-diameter --without-eldap > --without-jinterface --without-megaco --without-odbc > --with-wx-prefix=/usr/local/opt/wxmac > > > almost no issues, because I cannot make wx work. I haven't seen it working > for several years on my macbook =( > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon May 20 14:34:49 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 20 May 2019 15:34:49 +0300 Subject: [erlang-questions] Erlang 22.0 failed to compile on macOS HighSierra 10.13.6 In-Reply-To: References: Message-ID: Mojave On Mon, May 20, 2019 at 2:47 PM Frank Muller wrote: > Max > Are you under Mojave, or HighSierra? > /Frank > > macbook-pro:flussonic max$ clang --version >> Apple LLVM version 10.0.0 (clang-1000.11.45.5) >> Target: x86_64-apple-darwin18.2.0 >> Thread model: posix >> InstalledDir: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin >> >> >> Compiled 22.0 without any issues: >> >> ./configure --prefix=/usr/local/Cellar/erlang/22.0 --enable-threads >> --enable-dirty-schedulers --enable-smp-support --enable-kernel-poll >> --enable-m64-build --with-dynamic-trace=dtrace --without-javac --with-wx >> --with-microstate-accounting=extra --enable-hipe --enable-lock-counter >> --with-ssl=/usr/local/opt/openssl --without-diameter --without-eldap >> --without-jinterface --without-megaco --without-odbc >> --with-wx-prefix=/usr/local/opt/wxmac >> >> >> almost no issues, because I cannot make wx work. I haven't seen it >> working for several years on my macbook =( >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Mon May 20 15:01:35 2019 From: otp@REDACTED (Erlang/OTP) Date: Mon, 20 May 2019 15:01:35 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.1 Released Message-ID: <20190520130135.GA15122@erix.ericsson.se> Patch Package: OTP 22.0.1 Git Tag: OTP-22.0.1 Date: 2019-05-20 Trouble Report Id: OTP-15825 Seq num: ERL-934 System: OTP Release: 22 Application: ssl-9.3.1 Predecessor: OTP 22.0 Check out the git tag OTP-22.0.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-9.3.1 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.3.1 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15825 Application(s): ssl Related Id(s): ERL-934, OTP-15823 Missing check of size of user_data_buffer made internal socket behave as an active socket instead of active N. This could cause memory problems. Full runtime dependencies of ssl-9.3.1: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From frank.muller.erl@REDACTED Mon May 20 17:30:21 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Mon, 20 May 2019 17:30:21 +0200 Subject: [erlang-questions] Erlang 22.0 failed to compile on macOS HighSierra 10.13.6 In-Reply-To: References: Message-ID: I?m still using HighSierra. Can you please share you ~/.kerlrc? /Frank Mojave > > On Mon, May 20, 2019 at 2:47 PM Frank Muller > wrote: > >> Max >> Are you under Mojave, or HighSierra? >> /Frank >> >> macbook-pro:flussonic max$ clang --version >>> Apple LLVM version 10.0.0 (clang-1000.11.45.5) >>> Target: x86_64-apple-darwin18.2.0 >>> Thread model: posix >>> InstalledDir: >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin >>> >>> >>> Compiled 22.0 without any issues: >>> >>> ./configure --prefix=/usr/local/Cellar/erlang/22.0 --enable-threads >>> --enable-dirty-schedulers --enable-smp-support --enable-kernel-poll >>> --enable-m64-build --with-dynamic-trace=dtrace --without-javac --with-wx >>> --with-microstate-accounting=extra --enable-hipe --enable-lock-counter >>> --with-ssl=/usr/local/opt/openssl --without-diameter --without-eldap >>> --without-jinterface --without-megaco --without-odbc >>> --with-wx-prefix=/usr/local/opt/wxmac >>> >>> >>> almost no issues, because I cannot make wx work. I haven't seen it >>> working for several years on my macbook =( >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Mon May 20 19:15:47 2019 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 20 May 2019 13:15:47 -0400 Subject: [erlang-questions] VSCode with Erlang extension Message-ID: Hi, If anyone is using VSCode with the Erlang extension, how do you enable hover help for standard functions? I see that the extension is supposed to support it, but it doesn't seem to work. Best, Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.santomaggio@REDACTED Mon May 20 21:19:49 2019 From: g.santomaggio@REDACTED (Gabriele Santomaggio) Date: Mon, 20 May 2019 21:19:49 +0200 Subject: [erlang-questions] Erlang scheduler segfault at ffffffffffffffff Message-ID: Hi, I am having the following the problem: 2019-05-06T10:46:16.413758+00:00 d98-f2-b3-c8-b8-65 kernel: [8649388.905125] ../mm/pgtable-generic.c:33: bad pmd ffff883eed530398(80000037db2008e7) 2019-05-06T10:46:16.423251+00:00 d98-f2-b3-c8-b8-65 kernel: [8649388.915722] 34_scheduler[15882]: segfault at ffffffffffffffff ip 0000000040e97113 sp 00007fcffdb7ef78 error 5 it causes a crash without erlang dump. HIPE is enabled, do you have an idea if is related in some way to hipe? notes: 1 - Erlang version 20.2.2 2 - 34_scheduler` is one of the erlang schedulers 3- It is not systematic, it happens randomly 4- I have some "notice: High CPU load detected: 997.159973" around the problem 5- I ended up on https://lkml.org/lkml/2017/4/10/152 I am looking if it could be related (??!?). ( let me try also here, I have already asked on the Erlang slack channel :) ) Thank you -- Gabriele Santomaggio -------------- next part -------------- An HTML attachment was scrubbed... URL: From alangingras@REDACTED Mon May 20 23:15:21 2019 From: alangingras@REDACTED (Alan Gingras) Date: Mon, 20 May 2019 17:15:21 -0400 Subject: [erlang-questions] VSCode with Erlang extension In-Reply-To: References: Message-ID: <004701d50f51$23468750$69d395f0$@comcast.net> Hi, I am using the extension with the latest version of VSCode and hover help is working for both standard functions and those in my ?project?. As far as I can tell there is no setting to turn it on or off specifically for Erlang. If you look for ?hover help? in preferences there is a ?Editor > Hover:Enabled? option. Hope this helps. Sincerely yours, Alan From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Serge Aleynikov Sent: Monday, May 20, 2019 13:16 To: Erlang Questions Subject: [erlang-questions] VSCode with Erlang extension Hi, If anyone is using VSCode with the Erlang extension, how do you enable hover help for standard functions? I see that the extension is supposed to support it, but it doesn't seem to work. Best, Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity@REDACTED Mon May 20 23:25:07 2019 From: icfp.publicity@REDACTED (Sam Tobin-Hochstadt) Date: Mon, 20 May 2019 17:25:07 -0400 Subject: [erlang-questions] Second Call for Tutorial Proposals: ICFP 2019 Message-ID: <5ce31b334dc25_3be82b1fe4fb05d46288d@homer.mail> *EXTENDED DEADLINE* - CALL FOR TUTORIAL PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Tutorials may occur after ICFP co-located with the associated workshops, from August 22 till August 23. ---------------------------------------------------------------------- Submission details Deadline for submission: June 3rd, 2019 Notification of acceptance: June 10th, 2019 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2018 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019@REDACTED by June 3rd, 2019. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by June 10th, 2019. The proposal form is available at: http://www.icfpconference.org/icfp2019-files/icfp19-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2019 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: Fran?ois Pottier ( Inria, France) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019@REDACTED From boyofmonk@REDACTED Tue May 21 05:39:36 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Tue, 21 May 2019 11:39:36 +0800 Subject: [erlang-questions] How to view the content of memory using gdb Message-ID: Hi all: My cowboy server occasionally crashe? I suspect that the data of the query is too large? but I don't know how to view the content of memory using gdb to find the detail data. ``` sudo gdb /home/q/erlang1705/lib/erlang/erts-6.4/bin/beam.smp core.18269 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /home/q/erlang1705/lib/erlang/erts-6.4/bin/beam.smp...done. [New LWP 18288] [New LWP 18274] [New LWP 18276] [New LWP 18289] [New LWP 18281] [New LWP 18273] [New LWP 18280] [New LWP 18278] [New LWP 18277] [New LWP 18284] [New LWP 18282] [New LWP 18275] [New LWP 18287] [New LWP 18285] [New LWP 18291] [New LWP 18269] [New LWP 18279] [New LWP 18286] [New LWP 18292] [New LWP 18290] [New LWP 18271] [New LWP 18272] [New LWP 18283] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/home/q/erlang1705/lib/erlang/erts-6.4/bin/beam.smp -- -root /home/q/erlang1705'. Program terminated with signal 6, Aborted. #0 0x00007fda423b55f7 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.17-106.el7_2.8.x86_64 ncurses-libs-5.9-13.20130511.el7.x86_64 zlib-1.2.7-15.el7.x86_64 (gdb) bt #0 0x00007fda423b55f7 in raise () from /lib64/libc.so.6 #1 0x00007fda423b6ce8 in abort () from /lib64/libc.so.6 #2 0x000000000045806e in erl_exit_vv (n=1, flush_async=flush_async@REDACTED=0, fmt=fmt@REDACTED=0x5fbce8 "%s: Cannot %s %lu bytes of memory (of type \"%s\", thread %d).\n", args1=args1@REDACTED=0x7fda361ba830, args2=args2@REDACTED =0x7fda361ba848) at beam/erl_init.c:2123 #3 0x0000000000458308 in erl_exit (n=n@REDACTED=1, fmt=fmt@REDACTED=0x5fbce8 "%s: Cannot %s %lu bytes of memory (of type \"%s\", thread %d).\n") at beam/erl_init.c:2133 #4 0x000000000043c4c1 in erts_alc_fatal_error (error=error@REDACTED=1, func=, func@REDACTED=0, n=n@REDACTED=155) at beam/erl_alloc.c:1875 #5 0x000000000043c507 in erts_alloc_n_enomem (n=n@REDACTED=155, size=size@REDACTED=4723591984) at beam/erl_alloc.c:1900 #6 0x0000000000529023 in erts_alloc (size=4723591984, type=19862) at beam/erl_alloc.h:228 #7 minor_collection (recl=, nobj=2, objv=0x7fda415d0380, need=0, p=0x7fda40a46a58) at beam/erl_gc.c:852 #8 erts_garbage_collect (p=p@REDACTED=0x7fda40a46a58, need=need@REDACTED=0, objv=0x7fda415d0380, nobj=2) at beam/erl_gc.c:450 #9 0x00000000005291d5 in erts_gc_after_bif_call (p=0x7fda40a46a58, result=0, regs=, arity=) at beam/erl_gc.c:362 #10 0x000000000056e99c in process_main () at beam/beam_emu.c:3578 #11 0x00000000004a734a in sched_thread_func (vesdp=0x7fda398acd40) at beam/erl_process.c:7695 #12 0x00000000005f6eb5 in thr_wrapper (vtwd=0x7ffcbf9b3b70) at pthread/ethread.c:106 #13 0x00007fda42951dc5 in start_thread () from /lib64/libpthread.so.0 #14 0x00007fda42476ced in clone () from /lib64/libc.so.6 (gdb) 9 Undefined command: "9". Try "help". (gdb) f 9 #9 0x00000000005291d5 in erts_gc_after_bif_call (p=0x7fda40a46a58, result=0, regs=, arity=) at beam/erl_gc.c:362 362 cost = erts_garbage_collect(p, 0, regs, p->arity); (gdb) source /home/q/lffan.liu/download/otp_src_17.5/erts/etc/unix/ etp-commands.in %--------------------------------------------------------------------------- % 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: 17 ERTS version: 6.4 Compile date: Thu Apr 11 12:23:01 2019 Arch: x86_64-unknown-linux-gnu Endianness: Little Word size: 64-bit Halfword: no HiPE support: yes SMP support: yes Thread support: yes Kernel poll: Supported but not used Debug compiled: no Lock checking: no Lock counting: no Node name: 'ejb_http_server@REDACTED' Number of schedulers: 8 Number of async-threads: 10 -------------------------------------------------- (gdb) etp-stackdump p % Stackdump (21): #Cp. #Cp. #Cp. #Cp. #Cp. {http_req,#Port<0.101737>,ranch_tcp,keepalive,<0.15468.5>,#SubBinary<0x4,0,0xde010000:0x13fffcd2>,'HTTP/1.1',{{10,88,193,24},13758},#SubBinary<0xf,0,0x10000:0x13fffd2a>,undefined,80,#SubBinary<0x13,0,0xde000000:0x13fffd5a>,undefined,#SubBinary<0x48,0,0xde010000:0x13fffd8a>,undefined,[],[{#SubBinary<0x4,0,0xde010000:0x13fffffa>,#SubBinary<0xf,0,0x10000:0x1400002a>},{0.000000,#HeapBinary<0x2,0xffff3839>},{#SubBinary<0xf,0,0xd5010000:0x1400026a>,#SubBinary<0xd,0,0x10000:0x1400029a>},{#SubBinary<0xf,0,0xde010000:0x14000382>,#SubBinary<0xa,0,0x10000:0x140003b2>},{#SubBinary<0xa,0,0x10000:0x140004c2>,#SubBinary<0xb,0,0x10000:0x140004f2>},{#SubBinary<0xc,0,0x10000:0x14000612>,#SubBinary<0x21,0,0x10000:0x14000642>},{#SubBinary<0x6,0,0xde010000:0x14000792>,#SubBinary<0x18,0,0x10000:0x140007c2>},{#SubBinary<0x9,0,0xde010000:0x14000912>,#SubBinary<0xe,0,0xde010000:0x14000942>},{#SubBinary<0xd,0,0xde010000:0x14000a72>,#SubBinary<0x5,0,0x10000:0x14000aa2>},{#SubBinary<0xf,0,0xde010000:0x14000bba>,#SubBinary<0xe,0,0x10000:0x14000bea>}],[{0.000000,98},{0.000000,undefined},{0.000000,98}],undefined,[],...}. #Cp. []. undefined. []. #Cp. []. []. undefined. http_get_history. {state,[{handler,http_get_history},{handler_opts,[]},{listener,http},{dispatch,[{'_',[],[{[#RefcBinary<0x8,0x13fffcd0,0x311dfa20,0x311dfa38,0>],[],http_getusers,[]},{[#RefcBinary<0x7,0x140006f8,0x311c3288,0x311c32a0,0>],[],http_getdeps,[]},{[#RefcBinary<0xb,0x14000878,0x311e9fc0,0x311e9fd8,0>],[],http_getmsgs,[]},{[#RefcBinary<0xd,0x140009d8,0x311c2d10,0x311c2d28,0>],[],http_getonlineuser,[]},{[#RefcBinary<0xe,0x14000b20,0x311c2d50,0x311c2d68,0>],[],http_getonlineuser2,[]},{[#RefcBinary<0xe,0x14000c18,0x311e9e40,0x311e9e58,0>],[],http_get_adjacentmsg,...},{[...],[],...},{[...],...},{...},...]}]},{max_connections,infinity}],false,0,5000,infinity,undefined,false}. {http_req,#Port<0.101737>,ranch_tcp,keepalive,<0.15468.5>,#SubBinary<0x4,0,0xde010000:0x13fffcd2>,'HTTP/1.1',{{10,88,193,24},13758},#SubBinary<0xf,0,0x10000:0x13fffd2a>,undefined,80,#SubBinary<0x13,0,0xde000000:0x13fffd5a>,undefined,#SubBinary<0x48,0,0xde010000:0x13fffd8a>,undefined,[],[{#SubBinary<0x4,0,0xde010000:0x13fffffa>,#SubBinary<0xf,0,0x10000:0x1400002a>},{#SubBinary<0xe,0,0xde010000:0x140001ba>,#SubBinary<0x2,0,0xde010000:0x140001ea>},{#SubBinary<0xf,0,0xd5010000:0x1400026a>,#SubBinary<0xd,0,0x10000:0x1400029a>},{#SubBinary<0xf,0,0xde010000:0x14000382>,#SubBinary<0xa,0,0x10000:0x140003b2>},{#SubBinary<0xa,0,0x10000:0x140004c2>,#SubBinary<0xb,0,0x10000:0x140004f2>},{#SubBinary<0xc,0,0x10000:0x14000612>,#SubBinary<0x21,0,0x10000:0x14000642>},{#SubBinary<0x6,0,0xde010000:0x14000792>,#SubBinary<0x18,0,0x10000:0x140007c2>},{#SubBinary<0x9,0,0xde010000:0x14000912>,#SubBinary<0xe,0,0xde010000:0x14000942>},{#SubBinary<0xd,0,0xde010000:0x14000a72>,#SubBinary<0x5,0,0x10000:0x14000aa2>},{#SubBinary<0xf,0,0xde010000:0x14000bba>,#SubBinary<0xe,0,0x10000:0x14000bea>}],[{0.000000,98},{0.000000,[Cannot access memory at address 0x18 (gdb) etp-process etp-process-info etp-process-memory-info etp-processes etp-processes-memory (gdb) etp-process-info p Pid: <0.15468.5> State: garbage-collecting | running | active | prq-prio-normal | usr-prio-normal | act-prio-normal Current function: lists:reverse/2 CP: #Cp I: #Cp<0x3ff50a70> Heap size: 492040832 Mbuf size: 160000 Msgq len: 0 (inner=0, outer=0) Parent: <0.600.0> Pointer: (Process *) 0x7fda40a46a58 ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc@REDACTED Tue May 21 08:50:16 2019 From: marc@REDACTED (Marc Worrell) Date: Tue, 21 May 2019 08:50:16 +0200 Subject: [erlang-questions] How to view the content of memory using gdb In-Reply-To: References: Message-ID: <776C14C4-96BA-4A74-9179-2919F71289AE@worrell.nl> Do you have some other logs? Preferably the one where the message below is printed. > On 21 May 2019, at 05:39, Monk Boy wrote: > > #2 0x000000000045806e in erl_exit_vv (n=1, flush_async=flush_async@REDACTED=0, fmt=fmt@REDACTED=0x5fbce8 "%s: Cannot %s %lu bytes of memory (of type \"%s\", thread %d).\n", args1=args1@REDACTED=0x7fda361ba830, args2=args2@REDACTED=0x7fda361ba848) > at beam/erl_init.c:2123 This could be out of memory, but also something else ?Cannot %s? ? If it is OOM then you can easily check the memory usage of beam.smp whilst it is running. That would give enough hints. Also check your running server with ?etop?. Cowboy has configurations max request content length, it will refuse the request with a 4xx error. Afaik it defaults to 64K for urlencoded bodies and 8M for other bodies. - Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From eckard.brauer@REDACTED Tue May 21 09:18:19 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Tue, 21 May 2019 09:18:19 +0200 Subject: [erlang-questions] How to view the content of memory using gdb In-Reply-To: <776C14C4-96BA-4A74-9179-2919F71289AE@worrell.nl> References: <776C14C4-96BA-4A74-9179-2919F71289AE@worrell.nl> Message-ID: <20190521091819.7f993bf7@gmx.de> Hi, stack frames 6..4 seem to point to a OOM condition: #4? 0x000000000043c4c1 in erts_alc_fatal_error (error=error@REDACTED=1, func=, func@REDACTED=0, n=n@REDACTED=155) at beam/erl_alloc.c:1875 #5? 0x000000000043c507 in erts_alloc_n_enomem (n=n@REDACTED=155, size=size@REDACTED=4723591984) at beam/erl_alloc.c:1900 #6? 0x0000000000529023 in erts_alloc (size=4723591984, type=19862) at beam/erl_alloc.h:228 as first memory seems to be requested by erts_alloc() in #6, then it's detected that no more memory is available and erts_alloc_n_enomem() is called because of that (#5; still at C level) what is turned into a fatal error at Erlang level too in #4, erts_alc_fatal_error(). For viewing memory content, it's good to know both the currently executed code and the involved C structs before, to be able to jump along that IIRC. Look at gdb's "print" command ("help print"). If the binary/binaries is/are not stripped, you can also use symbolic names, what makes things much easier, and you can examine source code with "list" (help list). For the rest, "disassemble" and some knowledge of the machine's/processor's assembly language is helpful. That only for short, it's a while since, and I'd have to try it on a "living body" again to clearer describe... Indeed, best would be to have the correct Erlang log. Cheers, Eckard Am Tue, 21 May 2019 08:50:16 +0200 schrieb Marc Worrell : > Do you have some other logs? > Preferably the one where the message below is printed. > > > On 21 May 2019, at 05:39, Monk Boy wrote: > > > > #2 0x000000000045806e in erl_exit_vv (n=1, > > flush_async=flush_async@REDACTED=0, fmt=fmt@REDACTED=0x5fbce8 "%s: Cannot > > %s %lu bytes of memory (of type \"%s\", thread %d).\n", > > args1=args1@REDACTED=0x7fda361ba830, args2=args2@REDACTED=0x7fda361ba848) > > at beam/erl_init.c:2123 > > This could be out of memory, but also something else ?Cannot %s? ? > > If it is OOM then you can easily check the memory usage of beam.smp > whilst it is running. That would give enough hints. > > Also check your running server with ?etop?. > > Cowboy has configurations max request content length, it will refuse > the request with a 4xx error. Afaik it defaults to 64K for urlencoded > bodies and 8M for other bodies. > > - Marc > -- :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Digitale Signatur von OpenPGP URL: From lukas@REDACTED Tue May 21 09:33:09 2019 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 21 May 2019 09:33:09 +0200 Subject: [erlang-questions] How to view the content of memory using gdb In-Reply-To: References: Message-ID: Hello, If you upgrade to Erlang/OTP vsn 20.3 or later this information is part of the crash dump so that you can use tools such as crash dump viewer to get this information. If you want etp to not cut data you need to do: set $etp_max_depth = 20000 set $etp_max_string_length = 10000 before you call any term printing function. You can also print the entire heap of the process using: etp-heapdump p This will dump a lot of data that will need to dig through to try to find what is taking all of the memory. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From boyofmonk@REDACTED Tue May 21 09:26:19 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Tue, 21 May 2019 15:26:19 +0800 Subject: [erlang-questions] How to view the content of memory using gdb In-Reply-To: <776C14C4-96BA-4A74-9179-2919F71289AE@worrell.nl> References: <776C14C4-96BA-4A74-9179-2919F71289AE@worrell.nl> Message-ID: Because the memory suddenly rises , no time to run 'etop'. I suspect that the responseof the request is too large, and the flood-like keep-alive request caused such a result. Marc Worrell ?2019?5?21??? ??2:50??? > Do you have some other logs? > Preferably the one where the message below is printed. > > On 21 May 2019, at 05:39, Monk Boy wrote: > > #2 0x000000000045806e in erl_exit_vv (n=1, flush_async=flush_async@REDACTED=0, > fmt=fmt@REDACTED=0x5fbce8 "%s: Cannot %s %lu bytes of memory (of type > \"%s\", thread %d).\n", args1=args1@REDACTED=0x7fda361ba830, > args2=args2@REDACTED=0x7fda361ba848) > at beam/erl_init.c:2123 > > > This could be out of memory, but also something else ?Cannot %s? ? > > If it is OOM then you can easily check the memory usage of beam.smp whilst > it is running. > That would give enough hints. > > Also check your running server with ?etop?. > > Cowboy has configurations max request content length, it will refuse the > request with a 4xx error. > Afaik it defaults to 64K for urlencoded bodies and 8M for other bodies. > > - Marc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boyofmonk@REDACTED Tue May 21 10:02:48 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Tue, 21 May 2019 16:02:48 +0800 Subject: [erlang-questions] How to view the content of memory using gdb In-Reply-To: References: Message-ID: Thanks for the tip! I will do it now. Lukas Larsson ?2019?5?21??? ??3:33??? > Hello, > > If you upgrade to Erlang/OTP vsn 20.3 or later this information is part of > the crash dump so that you can use tools such as crash dump viewer to get > this information. > > If you want etp to not cut data you need to do: > > set $etp_max_depth = 20000 > set $etp_max_string_length = 10000 > > before you call any term printing function. You can also print the entire > heap of the process using: > > etp-heapdump p > > This will dump a lot of data that will need to dig through to try to find > what is taking all of the memory. > > Lukas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Tue May 21 13:26:28 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Tue, 21 May 2019 13:26:28 +0200 Subject: [erlang-questions] Erlang scheduler segfault at ffffffffffffffff In-Reply-To: References: Message-ID: On Mon, May 20, 2019 at 9:20 PM Gabriele Santomaggio wrote: > > Hi, > I am having the following the problem: > > 2019-05-06T10:46:16.413758+00:00 d98-f2-b3-c8-b8-65 kernel: [8649388.905125] ../mm/pgtable-generic.c:33: bad pmd ffff883eed530398(80000037db2008e7) > 2019-05-06T10:46:16.423251+00:00 d98-f2-b3-c8-b8-65 kernel: [8649388.915722] 34_scheduler[15882]: segfault at ffffffffffffffff ip 0000000040e97113 sp 00007fcffdb7ef78 error 5 > > it causes a crash without erlang dump. > > HIPE is enabled, do you have an idea if is related in some way to hipe? > > notes: > 1 - Erlang version 20.2.2 > 2 - 34_scheduler` is one of the erlang schedulers This is a kernel bug, plain and simple. OTP and/or HiPE _might_ do something that triggers it, but that's just coincidental; a correct kernel must not crash due to (unprivileged) user-space actions. You don't say what kernel you're running, but you should consider upgrading it. (Long shot: may also be a bug in the C compiler used to compile the kernel, but that's extremely uncommon for vanilla distribution kernels.) From g.santomaggio@REDACTED Wed May 22 08:25:54 2019 From: g.santomaggio@REDACTED (Gabriele Santomaggio) Date: Wed, 22 May 2019 08:25:54 +0200 Subject: [erlang-questions] Erlang scheduler segfault at ffffffffffffffff In-Reply-To: References: Message-ID: Thank you Mikael, We run: uname -a Linux [x] 4.4.121-92.98-default #1 SMP Fri Oct 19 07:52:13 UTC 2018 (e4d85ce) x86_64 x86_64 x86_64 GNU/Linux We will update the kernel. - Gabriele Santomaggio Il giorno mar 21 mag 2019 alle ore 13:26 Mikael Pettersson < mikpelinux@REDACTED> ha scritto: > On Mon, May 20, 2019 at 9:20 PM Gabriele Santomaggio > wrote: > > > > Hi, > > I am having the following the problem: > > > > 2019-05-06T10:46:16.413758+00:00 d98-f2-b3-c8-b8-65 kernel: > [8649388.905125] ../mm/pgtable-generic.c:33: bad pmd > ffff883eed530398(80000037db2008e7) > > 2019-05-06T10:46:16.423251+00:00 d98-f2-b3-c8-b8-65 kernel: > [8649388.915722] 34_scheduler[15882]: segfault at ffffffffffffffff ip > 0000000040e97113 sp 00007fcffdb7ef78 error 5 > > > > it causes a crash without erlang dump. > > > > HIPE is enabled, do you have an idea if is related in some way to hipe? > > > > notes: > > 1 - Erlang version 20.2.2 > > 2 - 34_scheduler` is one of the erlang schedulers > > This is a kernel bug, plain and simple. OTP and/or HiPE _might_ do > something that triggers it, but that's just coincidental; a correct > kernel must not crash due to (unprivileged) user-space actions. > > You don't say what kernel you're running, but you should consider > upgrading it. > > (Long shot: may also be a bug in the C compiler used to compile the > kernel, but that's extremely uncommon for vanilla distribution > kernels.) > -- Gabriele Santomaggio -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlsson.rm@REDACTED Thu May 23 15:54:22 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Thu, 23 May 2019 15:54:22 +0200 Subject: [erlang-questions] Nif and driver callbacks Message-ID: Hi, I just started to write some nif code to interface towards a Linux driver API. I can install a callback function in my nif module that gets called from the driver whenever it is ready to receive new data. Currently it gets called every 5 ms. The callback function sends a message to an erlang process that in turn delivers new data to the driver. (Using another nif function). This works, although I am a bit puzzled how, since the callback function that is called from the linux driver appearantly is running outside the Erlang VM and still is able to send a message to the erlang process. Could anyone explain how this works? Also when loaded with a lot of data I am not capable of delivering in time (5 ms) unless I set the process_flag(priority, high). I noticed there is a enif_select function that I can use instead but this also sends a message to an erlang process so I am not sure if there is any timing difference between using enif_select or sending an erlang message directly from a driver callback? Thanks, Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Thu May 23 20:42:37 2019 From: sverker@REDACTED (Sverker Eriksson) Date: Thu, 23 May 2019 20:42:37 +0200 Subject: [erlang-questions] Nif and driver callbacks In-Reply-To: References: Message-ID: <1558636957.5926.12.camel@erlang.org> On tor, 2019-05-23 at 15:54 +0200, Mikael Karlsson wrote: > Hi, > I just started to write some nif code to interface towards a Linux driver API. > I can install a callback function in my nif module that gets called from the > driver? whenever it is ready to receive new data. Currently it gets called > every 5 ms. The callback function sends a message to an erlang process that in > turn delivers new data to the driver. (Using another nif function). > > This works, although I am a bit puzzled how, since the callback function that > is called from the linux driver appearantly is running outside the Erlang VM > and still is able to send a message to the erlang process. Could anyone > explain how this works? > If your callback function calls enif_send to send the message and the message arrives, then apparently it's running within the Erlang VM. If in doubt: 1. Enable core dump generation (ulimit -c, /proc/sys/kernel/core_pattern, etc). 2. Put a call to abort() in your callback. 3. Run and watch your beam.smp crash. 4. Do post mortem with "gdb beam.smp " 5. Use 'backtrace' command to see who is calling you. /Sverker From karlsson.rm@REDACTED Sat May 25 22:17:11 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Sat, 25 May 2019 22:17:11 +0200 Subject: [erlang-questions] Nif and driver callbacks In-Reply-To: References: Message-ID: Thu May 23 20:42:37 CEST 2019 Sverker Ericsson wrote: > On tor, 2019-05-23 at 15:54 +0200, Mikael Karlsson wrote: >> Hi, >> I just started to write some nif code to interface towards a Linux driver API. >> I can install a callback function in my nif module that gets called from the >> driver whenever it is ready to receive new data. Currently it gets called >> every 5 ms. The callback function sends a message to an erlang process that in >> turn delivers new data to the driver. (Using another nif function). >> >> This works, although I am a bit puzzled how, since the callback function that >> is called from the linux driver appearantly is running outside the Erlang VM >> and still is able to send a message to the erlang process. Could anyone >> explain how this works? >> > If your callback function calls enif_send to send the message and the message > arrives, then apparently it's running within the Erlang VM. > > If in doubt: > 1. Enable core dump generation (ulimit -c, /proc/sys/kernel/core_pattern, etc). > 2. Put a call to abort() in your callback. > 3. Run and watch your beam.smp crash. > 4. Do post mortem with "gdb beam.smp " > 5. Use 'backtrace' command to see who is calling you. > /Sverker Thanks, I am using enif_send and I realise that it is running within the VM (beam.smp) process now. And it works fine even though I am still wondering how the asynchronous notification plays together with the Erlang scheduling, or maybe it doesn't need to, but just works anyway. Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From boyofmonk@REDACTED Mon May 27 13:51:13 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Mon, 27 May 2019 19:51:13 +0800 Subject: [erlang-questions] ubuntu1804 install erlang with source: No usable OpenSSL found Message-ID: Hi all: When I configure the otp_src, I got this: ``` memacs@REDACTED:~/??/otp_src_19.3$ ./configure --prefix=/home/memacs/opt/erlang/1903 ............................ checking whether MAP_FIXED is declared... yes checking whether MAP_NORESERVE is declared... yes configure: WARNING: Security feature -fPIE will be disabled for HiPE configure: Floating point exceptions disabled by default on Linux checking whether to redefine FD_SETSIZE... no configure: Enable exec_alloc for hipe code allocation checking for working poll()... yes checking whether epoll is level triggered... yes checking whether kernel poll support should be enabled... yes; epoll checking whether putenv() stores a copy of the key-value pair... no checking for ld... gcc checking for compiler flags for loadable drivers... -g -O2 -I/home/memacs/??/otp_src_19.3/erts/x86_64-unknown-linux-gnu -fno-tree-copyrename -D_GNU_SOURCE -fPIC checking for linker for loadable drivers... gcc checking for linker flags for loadable drivers... -shared -Wl,-Bsymbolic checking for 'runtime library path' linker flag... -Wl,-R checking for a compiler that handles jumptables... gcc checking for static ZLib to be used by SSL in standard locations... no checking for OpenSSL >= 0.9.7 in standard locations... found; but not usable configure: WARNING: No (usable) OpenSSL found, skipping ssl, ssh and crypto applications checking for kstat_open in -lkstat... (cached) no checking for kvm_open in -lkvm... no checking for javac.sh... no checking for javac... javac checking for JDK version 1.6... no configure: WARNING: Could not find any usable java compiler, will skip: jinterface checking for c++... c++ checking for log2... yes configure: creating ./config.status config.status: creating emulator/x86_64-unknown-linux-gnu/Makefile config.status: creating epmd/src/x86_64-unknown-linux-gnu/Makefile config.status: creating etc/common/x86_64-unknown-linux-gnu/Makefile config.status: creating include/internal/x86_64-unknown-linux-gnu/ethread.mk config.status: creating include/internal/x86_64-unknown-linux-gnu/ erts_internal.mk config.status: creating lib_src/x86_64-unknown-linux-gnu/Makefile config.status: creating Makefile config.status: creating ../make/x86_64-unknown-linux-gnu/otp.mk config.status: creating ../make/x86_64-unknown-linux-gnu/otp_ded.mk config.status: creating ../make/make_emakefile config.status: creating ../lib/ic/c_src/x86_64-unknown-linux-gnu/Makefile config.status: creating ../lib/os_mon/c_src/x86_64-unknown-linux-gnu/Makefile config.status: creating ../lib/crypto/c_src/x86_64-unknown-linux-gnu/Makefile config.status: creating ../lib/orber/c_src/x86_64-unknown-linux-gnu/Makefile config.status: creating ../lib/runtime_tools/c_src/x86_64-unknown-linux-gnu/Makefile config.status: creating ../lib/tools/c_src/x86_64-unknown-linux-gnu/Makefile config.status: creating x86_64-unknown-linux-gnu/config.h config.status: x86_64-unknown-linux-gnu/config.h is unchanged config.status: creating include/internal/x86_64-unknown-linux-gnu/ethread_header_config.h config.status: include/internal/x86_64-unknown-linux-gnu/ethread_header_config.h is unchanged config.status: creating include/x86_64-unknown-linux-gnu/erl_int_sizes_config.h config.status: include/x86_64-unknown-linux-gnu/erl_int_sizes_config.h is unchanged ********************************************************************* ********************** APPLICATIONS DISABLED ********************** ********************************************************************* crypto : No usable OpenSSL found jinterface : No Java compiler found ssh : No usable OpenSSL found ssl : No usable OpenSSL found ********************************************************************* ********************************************************************* ********************** APPLICATIONS INFORMATION ******************* ********************************************************************* wx : wxWidgets not found, wx will NOT be usable ********************************************************************* memacs@REDACTED:~/??/otp_src_19.3$ openssl version OpenSSL 1.1.0g 2 Nov 2017 memacs@REDACTED:~/??/otp_src_19.3$ uname -a Linux memacs-beam 4.18.0-20-generic #21~18.04.1-Ubuntu SMP Wed May 8 08:43:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux memacs@REDACTED:~/??/otp_src_19.3$ sudo apt-get install libssl-dev ?????????... ?? ????????????? ????????... ?? libssl-dev ?????? (1.1.0g-2ubuntu4.3)? ??? 0 ????????? 0 ???????? 0 ?????? 3 ????????? memacs@REDACTED:~/??/otp_src_19.3$ ``` The openssl is installed, but why it is unusable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Mon May 27 13:56:50 2019 From: g@REDACTED (Guilherme Andrade) Date: Mon, 27 May 2019 12:56:50 +0100 Subject: [erlang-questions] ubuntu1804 install erlang with source: No usable OpenSSL found In-Reply-To: References: Message-ID: Hello Monk Boy, On Mon, 27 May 2019 at 12:51, Monk Boy wrote: > The openssl is installed, but why it is unusable? > Erlang/OTP 19 is not compatible with OpenSSL 1.1.x, unfortunately. Related ticket in kerl repo: https://github.com/kerl/kerl/issues/226 -- Guilherme -------------- next part -------------- An HTML attachment was scrubbed... URL: From dm.klionsky@REDACTED Mon May 27 13:57:44 2019 From: dm.klionsky@REDACTED (Dmitry Klionsky) Date: Mon, 27 May 2019 14:57:44 +0300 Subject: [erlang-questions] ubuntu1804 install erlang with source: No usable OpenSSL found In-Reply-To: References: Message-ID: Hi, Had the same issue recently on Ubuntu 18.10. OTP 19.3 wants OpelSSL 1.0.x. Make/install OpenSSL: curl https://www.openssl.org/source/openssl-1.0.2r.tar.gz | tar xfz - && cd openssl-1.0.2r && ./config --prefix=/usr/local/openssl-1.0.2r -fpic && make && sudo make install && cd .. && rm -rf openssl-1.0.2r creates=/usr/local/openssl-1.0.2r Reconfigure/build OTP 19.3 with the flag --with-ssl=/usr/local/openssl-1.0.2r On 5/27/19 2:51 PM, Monk Boy wrote: > Hi all: > > When I configure the otp_src, I got this: > > ``` > memacs@REDACTED:~/??/otp_src_19.3$ ./configure > ?--prefix=/home/memacs/opt/erlang/1903 > > ............................ > checking whether MAP_FIXED is declared... yes > checking whether MAP_NORESERVE is declared... yes > configure: WARNING: Security feature -fPIE will be disabled for HiPE > configure: Floating point exceptions disabled by default on Linux > checking whether to redefine FD_SETSIZE... no > configure: Enable exec_alloc for hipe code allocation > checking for working poll()... yes > checking whether epoll is level triggered... yes > checking whether kernel poll support should be enabled... yes; epoll > checking whether putenv() stores a copy of the key-value pair... no > checking for ld... gcc > checking for compiler flags for loadable drivers... -g -O2 > -I/home/memacs/??/otp_src_19.3/erts/x86_64-unknown-linux-gnu > -fno-tree-copyrename ?-D_GNU_SOURCE -fPIC > checking for linker for loadable drivers... gcc > checking for linker flags for loadable drivers... -shared -Wl,-Bsymbolic > checking for 'runtime library path' linker flag... -Wl,-R > checking for a compiler that handles jumptables... gcc > checking for static ZLib to be used by SSL in standard locations... no > checking for OpenSSL >= 0.9.7 in standard locations... found; but not > usable > configure: WARNING: No (usable) OpenSSL found, skipping ssl, ssh and > crypto applications > checking for kstat_open in -lkstat... (cached) no > checking for kvm_open in -lkvm... no > checking for javac.sh... no > checking for javac... javac > checking for JDK version 1.6... no > configure: WARNING: Could not find any usable java compiler, will > skip: jinterface > checking for c++... c++ > checking for log2... yes > configure: creating ./config.status > config.status: creating emulator/x86_64-unknown-linux-gnu/Makefile > config.status: creating epmd/src/x86_64-unknown-linux-gnu/Makefile > config.status: creating etc/common/x86_64-unknown-linux-gnu/Makefile > config.status: creating > include/internal/x86_64-unknown-linux-gnu/ethread.mk > config.status: creating > include/internal/x86_64-unknown-linux-gnu/erts_internal.mk > > config.status: creating lib_src/x86_64-unknown-linux-gnu/Makefile > config.status: creating Makefile > config.status: creating ../make/x86_64-unknown-linux-gnu/otp.mk > > config.status: creating ../make/x86_64-unknown-linux-gnu/otp_ded.mk > > config.status: creating ../make/make_emakefile > config.status: creating ../lib/ic/c_src/x86_64-unknown-linux-gnu/Makefile > config.status: creating > ../lib/os_mon/c_src/x86_64-unknown-linux-gnu/Makefile > config.status: creating > ../lib/crypto/c_src/x86_64-unknown-linux-gnu/Makefile > config.status: creating > ../lib/orber/c_src/x86_64-unknown-linux-gnu/Makefile > config.status: creating > ../lib/runtime_tools/c_src/x86_64-unknown-linux-gnu/Makefile > config.status: creating > ../lib/tools/c_src/x86_64-unknown-linux-gnu/Makefile > config.status: creating x86_64-unknown-linux-gnu/config.h > config.status: x86_64-unknown-linux-gnu/config.h is unchanged > config.status: creating > include/internal/x86_64-unknown-linux-gnu/ethread_header_config.h > config.status: > include/internal/x86_64-unknown-linux-gnu/ethread_header_config.h is > unchanged > config.status: creating > include/x86_64-unknown-linux-gnu/erl_int_sizes_config.h > config.status: include/x86_64-unknown-linux-gnu/erl_int_sizes_config.h > is unchanged > ********************************************************************* > ********************** ?APPLICATIONS DISABLED ?********************** > ********************************************************************* > > crypto ? ? ? ? : No usable OpenSSL found > jinterface ? ? : No Java compiler found > ssh ? ? ? ? ? ?: No usable OpenSSL found > ssl ? ? ? ? ? ?: No usable OpenSSL found > > ********************************************************************* > ********************************************************************* > ********************** ?APPLICATIONS INFORMATION ?******************* > ********************************************************************* > > wx ? ? ? ? ? ? : wxWidgets not found, wx will NOT be usable > > ********************************************************************* > memacs@REDACTED:~/??/otp_src_19.3$ openssl version > OpenSSL 1.1.0g ?2 Nov 2017 > memacs@REDACTED:~/??/otp_src_19.3$ uname -a > Linux memacs-beam 4.18.0-20-generic #21~18.04.1-Ubuntu SMP Wed May 8 > 08:43:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > memacs@REDACTED:~/??/otp_src_19.3$ sudo apt-get install libssl-dev > ?????????... ?? > ????????????? > ????????... ?? > libssl-dev ?????? (1.1.0g-2ubuntu4.3)? > ??? 0 ????????? 0 ???????? 0 ?????? 3 > ????????? > memacs@REDACTED:~/??/otp_src_19.3$ > ``` > > The openssl is installed, but why it is unusable? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From boyofmonk@REDACTED Tue May 28 03:51:35 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Tue, 28 May 2019 09:51:35 +0800 Subject: [erlang-questions] ubuntu1804 install erlang with source: No usable OpenSSL found In-Reply-To: References: Message-ID: Ok, thanks. I will update openssl to solve it. Guilherme Andrade ?2019?5?27??? ??7:57??? > Hello Monk Boy, > > On Mon, 27 May 2019 at 12:51, Monk Boy wrote: > >> The openssl is installed, but why it is unusable? >> > > Erlang/OTP 19 is not compatible with OpenSSL 1.1.x, unfortunately. > > Related ticket in kerl repo: > https://github.com/kerl/kerl/issues/226 > > -- > Guilherme > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boyofmonk@REDACTED Tue May 28 05:32:05 2019 From: boyofmonk@REDACTED (Monk Boy) Date: Tue, 28 May 2019 11:32:05 +0800 Subject: [erlang-questions] ubuntu1804 install erlang with source: No usable OpenSSL found In-Reply-To: References: Message-ID: I have solved it with: ``` ./configure --prefix=/home/memacs/opt/erlang/1903 --with-ssl=/home/memacs/opt/openssl/openssl-1.0.2r ``` Monk Boy ?2019?5?28??? ??9:51??? > Ok, thanks. I will update openssl to solve it. > > Guilherme Andrade ?2019?5?27??? ??7:57??? > >> Hello Monk Boy, >> >> On Mon, 27 May 2019 at 12:51, Monk Boy wrote: >> >>> The openssl is installed, but why it is unusable? >>> >> >> Erlang/OTP 19 is not compatible with OpenSSL 1.1.x, unfortunately. >> >> Related ticket in kerl repo: >> https://github.com/kerl/kerl/issues/226 >> >> -- >> Guilherme >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl@REDACTED Mon May 27 11:01:52 2019 From: publicityifl@REDACTED (Jurriaan Hage) Date: Mon, 27 May 2019 02:01:52 -0700 Subject: [erlang-questions] Call for papers for IFL 2019 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the call for papers for IFL 2019. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- ================================================================================ IFL 2019 31st Symposium on Implementation and Application of Functional Languages National University of Singapore September 25th-27th, 2019 http://2019.iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2019 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Keynote Speaker * Olivier Danvy, Yale-NUS College ### Submissions and peer-review Differently from previous editions of IFL, IFL 2019 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2019. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: May 31, 2019 Submission of draft papers: July 15, 2019 Regular and draft papers notification: August 1, 2019 Deadline for early registration: August 15, 2019 Submission of pre-proceedings version: September 15, 2019 IFL Symposium: September 25-27, 2019 Submission of papers for post-proceedings: November 30, 2019 Notification of acceptance: January 31, 2020 Camera-ready version: February 29, 2020 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2019 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jurrien Stutterheim (Standard Chartered Bank Singapore), Wei Ngan Chin (National University of Singapore) Program Committee: - Olaf Chitil, University of Kent - Clemens Grelck, University of Amsterdam - Daisuke Kimura, Toho University - Pieter Koopman, Radboud University - Tamas Kozsik, Eotvos Lorand University - Roman Leschinskiy, Facebook - Ben Lippmeier, The University of New South Wales - Marco T. Morazan, Seton Hall University - Sven-Bodo Scholz, Heriot-Watt University - Tom Schrijvers, Katholieke Universiteit Leuven - Alejandro Serrano, Utrecht University - Tony Sloane, Macquarie University - Simon Thompson, University of Kent - Marcos Viera, Universidad de la Republica - Wei Ngan Chin, NUS - Jurrien Stutterheim, Standard Chartered Bank ### Venue The 31st IFL is organized by the National University of Singapore. Singapore is located in the heart of South-East Asia, and the city itself is extremely well connected by trains and taxis. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2019 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Tue May 28 11:14:29 2019 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 28 May 2019 11:14:29 +0200 Subject: [erlang-questions] no more logs using logger with common tests Message-ID: Hi all, I've switched my code to logger macros instead of using lager. But now I've no log stored on the filesystem ie in `_build/test/logs/ct_run.nonode\@nohost.2019-05-28_10.49.10/` or similar folder.. Any idea what could be the issue? I use following sys config: ``` [ {kernel, [ {logger_level, debug}, {logger, [{handler, default, logger_std_h, #{level => error, config => #{file => "log/erlang.log"}}}, {handler, info, logger_std_h, #{level => debug, config => #{file => "log/debug.log"}}} ]}]} ]. ``` ad my rebar.config: ``` ... {ct_opts, [ {sys_config, ["config/test.config"]}, {ct_hooks, [cth_surefire]} ]}. ``` Hope it helps, any idea is welcome :) Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Tue May 28 12:35:34 2019 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 28 May 2019 12:35:34 +0200 Subject: [erlang-questions] no more logs using logger with common tests In-Reply-To: References: Message-ID: Do you see any printout in the shell like Logger - error: {removed_failing_handler,default} ?? The log files should be created relative to your current work directory - but when trying similar configuration as you describe it seems logger fails pretty soon due to ct's change of current directory :( Can you try it once with an absolute path to verify if you're facing the same problem or if it's something else? Regards /siri tir. 28. mai 2019 kl. 11:14 skrev Benoit Chesneau : > Hi all, > > I've switched my code to logger macros instead of using lager. But now > I've no log stored on the filesystem ie in > `_build/test/logs/ct_run.nonode\@nohost.2019-05-28_10.49.10/` or similar > folder.. Any idea what could be the issue? > > > > I use following sys config: > > ``` > [ > {kernel, > [ > {logger_level, debug}, > > > {logger, > [{handler, default, logger_std_h, > #{level => error, > config => #{file => "log/erlang.log"}}}, > > {handler, info, logger_std_h, > #{level => debug, > config => #{file => "log/debug.log"}}} > ]}]} > ]. > ``` > > ad my rebar.config: > > ``` > ... > {ct_opts, [ > {sys_config, ["config/test.config"]}, > > {ct_hooks, [cth_surefire]} > > ]}. > ``` > > Hope it helps, any idea is welcome :) > > Benoit > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yestin@REDACTED Tue May 28 15:32:20 2019 From: yestin@REDACTED (Yestin L. Harrison) Date: Tue, 28 May 2019 06:32:20 -0700 Subject: [erlang-questions] Famous threads? Message-ID: I'm still relatively green to all this Erlang business. Considering that this list's first message predates my birth by a few months, and seeing references to threads everywhere from recordings of Erlang talks to StackOverflow answers, I was wondering if anyone could name any sort of "required reading" as it concerns design philosophy, shared culture, programming style, unspoken guidelines, heuristics, or anything else under the sun, that may only be obvious to relative veterans of this list. For instance, Garrett Smith's "Why the Cool Kids Don't Use Erlang" (2014) mentions the then-recent "bikeshed thread" that was apparently notorious enough to warrant a survey, and I can't for the life of me dig that out of the archive. If I can compile a list of such things, I may well be able to upload that somewhere for others' future reference. From elbrujohalcon@REDACTED Tue May 28 15:41:56 2019 From: elbrujohalcon@REDACTED (Brujo Benavides) Date: Tue, 28 May 2019 10:41:56 -0300 Subject: [erlang-questions] Famous threads? In-Reply-To: References: Message-ID: Hi Yestin, You can start with the links and references from http://spawnedshelter.com/ Cheers! On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison wrote: > I'm still relatively green to all this Erlang business. Considering that > this > list's first message predates my birth by a few months, and seeing > references > to threads everywhere from recordings of Erlang talks to StackOverflow > answers, > I was wondering if anyone could name any sort of "required reading" as it > concerns design philosophy, shared culture, programming style, unspoken > guidelines, heuristics, or anything else under the sun, that may only be > obvious to relative veterans of this list. For instance, Garrett Smith's > "Why > the Cool Kids Don't Use Erlang" (2014) mentions the then-recent "bikeshed > thread" that was apparently notorious enough to warrant a survey, and I > can't > for the life of me dig that out of the archive. If I can compile a list of > such things, I may well be able to upload that somewhere for others' future > reference. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Brujo Benavides about.me/elbrujohalcon -------------- next part -------------- An HTML attachment was scrubbed... URL: From list1@REDACTED Tue May 28 16:10:06 2019 From: list1@REDACTED (Grzegorz Junka) Date: Tue, 28 May 2019 14:10:06 +0000 Subject: [erlang-questions] Famous threads? In-Reply-To: References: Message-ID: <4bb69e1c-1fe9-7d7b-a4e2-37003b5132a7@gjunka.com> Wow, @Brujo, that's an excellent resource. Thanks for sharing! @yestin, the list is quite long, so to start somewhere I would recommend the very beginning, which would be Joe's PhD's thesis http://erlang.org/download/armstrong_thesis_2003.pdf (the link 8. in the Introduction, which should host the same document, doesn't seem to work). This gives a high-level view of the overall design principles. After that if you like verbose and explanatory writing then Learn you some Erlang book is pretty good, albeit quite long. Otherwise Erlang and OTP in Action is very good https://www.manning.com/books/erlang-and-otp-in-action GrzegorzJ On 28/05/2019 13:41, Brujo Benavides wrote: > Hi Yestin, > > You can start with the links and references from > http://spawnedshelter.com/ > > Cheers! > > On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison > wrote: > > I'm still relatively green to all this Erlang business. > Considering that this > list's first message predates my birth by a few months, and seeing > references > to threads everywhere from recordings of Erlang talks to > StackOverflow answers, > I was wondering if anyone could name any sort of "required > reading" as it > concerns design philosophy, shared culture, programming style, > unspoken > guidelines, heuristics, or anything else under the sun, that may > only be > obvious to relative veterans of this list. For instance, Garrett > Smith's "Why > the Cool Kids Don't Use Erlang" (2014) mentions the then-recent > "bikeshed > thread" that was apparently notorious enough to warrant a survey, > and I can't > for the life of me dig that out of the archive. If I can compile a > list of > such things, I may well be able to upload that somewhere for > others' future > reference. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > > > Brujo Benavides > about.me/elbrujohalcon > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanmartinguillen@REDACTED Tue May 28 16:17:27 2019 From: juanmartinguillen@REDACTED (=?UTF-8?Q?Juan_Mart=C3=ADn_Guill=C3=A9n?=) Date: Tue, 28 May 2019 14:17:27 +0000 (UTC) Subject: [erlang-questions] Famous threads? In-Reply-To: References: Message-ID: <309225388.5717484.1559053047266@mail.yahoo.com> The one Brujo is mentioning is great, I did't know about it. I would add Learn You Some Erlang: https://learnyousomeerlang.com/ And of course for the people of your generation the audiovisual and acclaimed "Erlang: The Movie": https://www.youtube.com/watch?v=uKfKtXYLG78 And the sequel: https://www.youtube.com/watch?v=rRbY3TMUcgQ Regards,Juan Mart?n. El martes, 28 de mayo de 2019 10:42:19 ART, Brujo Benavides escribi?: Hi Yestin, You can start with the links and references from?http://spawnedshelter.com/ Cheers! On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison wrote: I'm still relatively green to all this Erlang business. Considering that this list's first message predates my birth by a few months, and seeing references to threads everywhere from recordings of Erlang talks to StackOverflow answers, I was wondering if anyone could name any sort of "required reading" as it concerns design philosophy, shared culture, programming style, unspoken guidelines, heuristics, or anything else under the sun, that may only be obvious to relative veterans of this list. For instance, Garrett Smith's "Why the Cool Kids Don't Use Erlang" (2014) mentions the then-recent "bikeshed thread" that was apparently notorious enough to warrant a survey, and I can't for the life of me dig that out of the archive. If I can compile a list of such things, I may well be able to upload that somewhere for others' future reference. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- | | Brujo Benavides about.me/elbrujohalcon | _______________________________________________ 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 May 28 17:33:43 2019 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 28 May 2019 16:33:43 +0100 Subject: [erlang-questions] Application dependencies in Common Test? Message-ID: We run a bunch of system tests using Common Test, orchestrating (currently) 9 Erlang nodes, 4 golang processes, and 4 NodeJS processes. Those tests (and various CT hooks) have application dependencies. For example, we have something that uses hackney to check a web server response, and we have something that uses cowboy to _be_ a web server, so that we can respond to a request, and so on. We run the tests by invoking ct_run, something like this (trimmed for size): ct_run -pa _build/dev/lib/*/ebin \ -include $(abspath include) \ -dir $(SUITES_DIR) \ -ct_hooks $(CT_HOOKS) \ -erl_args \ -config sys.config \ -s system_tests In order to start the dependencies (hackney, cowboy, etc.), we use "-s system_tests" (as above), where system_tests:start/0 looks like this: start() -> {ok, _} = application:ensure_all_started(system_tests). ...and we have system_tests.app list our dependencies. Now (the reason I'm asking): this feels like we've unnecessarily coupled everything to system_tests.app: if we add a new assertion or fixture or one of our CT hooks wants to do something different, we need to add the relevant dependency to this one place. In fact, this one place only *exists* to list the application dependencies. Is there a better way to do this? Related: we've got a mixture of application env vars in the system_tests application, and values in CT config. That feels ... wrong as well. Any suggestions here? Thanks, Roger. From lloyd@REDACTED Tue May 28 18:26:08 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 28 May 2019 12:26:08 -0400 Subject: [erlang-questions] Famous threads? In-Reply-To: References: Message-ID: <8B8701B8-3EE6-4DCC-88AA-4907041AE6E1@writersglen.com> What an outstanding resource! Thank you, Bruno. Best wishes, LRP Sent from my iPad > On May 28, 2019, at 9:41 AM, Brujo Benavides wrote: > > Hi Yestin, > > You can start with the links and references from http://spawnedshelter.com/ > > Cheers! > >> On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison wrote: >> I'm still relatively green to all this Erlang business. Considering that this >> list's first message predates my birth by a few months, and seeing references >> to threads everywhere from recordings of Erlang talks to StackOverflow answers, >> I was wondering if anyone could name any sort of "required reading" as it >> concerns design philosophy, shared culture, programming style, unspoken >> guidelines, heuristics, or anything else under the sun, that may only be >> obvious to relative veterans of this list. For instance, Garrett Smith's "Why >> the Cool Kids Don't Use Erlang" (2014) mentions the then-recent "bikeshed >> thread" that was apparently notorious enough to warrant a survey, and I can't >> for the life of me dig that out of the archive. If I can compile a list of >> such things, I may well be able to upload that somewhere for others' future >> reference. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > Brujo Benavides > about.me/elbrujohalcon > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ola.a.andersson@REDACTED Tue May 28 19:18:55 2019 From: ola.a.andersson@REDACTED (Ola Andersson A) Date: Tue, 28 May 2019 17:18:55 +0000 Subject: [erlang-questions] Famous threads? In-Reply-To: References: Message-ID: This is a goldmine! Thank you so much Brujo. /Ola. From: erlang-questions-bounces@REDACTED On Behalf Of Brujo Benavides Sent: den 28 maj 2019 15:42 To: Yestin L. Harrison Cc: erlang-questions Subject: Re: [erlang-questions] Famous threads? Hi Yestin, You can start with the links and references from http://spawnedshelter.com/ Cheers! On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison > wrote: I'm still relatively green to all this Erlang business. Considering that this list's first message predates my birth by a few months, and seeing references to threads everywhere from recordings of Erlang talks to StackOverflow answers, I was wondering if anyone could name any sort of "required reading" as it concerns design philosophy, shared culture, programming style, unspoken guidelines, heuristics, or anything else under the sun, that may only be obvious to relative veterans of this list. For instance, Garrett Smith's "Why the Cool Kids Don't Use Erlang" (2014) mentions the then-recent "bikeshed thread" that was apparently notorious enough to warrant a survey, and I can't for the life of me dig that out of the archive. If I can compile a list of such things, I may well be able to upload that somewhere for others' future reference. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- Brujo Benavides about.me/elbrujohalcon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6320 bytes Desc: not available URL: From karlsson.rm@REDACTED Tue May 28 22:23:43 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Tue, 28 May 2019 22:23:43 +0200 Subject: [erlang-questions] Application dependencies in Common Test? In-Reply-To: References: Message-ID: Tue 28 May 2019 17:34 Roger Lipscombe wrote: > > We run a bunch of system tests using Common Test, orchestrating > (currently) 9 Erlang nodes, 4 golang processes, and 4 NodeJS > processes. > .. > > We run the tests by invoking ct_run, something like this (trimmed for size): > > ct_run -pa _build/dev/lib/*/ebin \ > -include $(abspath include) \ > -dir $(SUITES_DIR) \ > -ct_hooks $(CT_HOOKS) \ > -erl_args \ > -config sys.config \ > -s system_tests > > In order to start the dependencies (hackney, cowboy, etc.), we use "-s > system_tests" (as above), where system_tests:start/0 looks like this: > > start() -> {ok, _} = application:ensure_all_started(system_tests). > > ...and we have system_tests.app list our dependencies. > ... > Is there a better way to do this? > ... > Thanks, > Roger. If it doesn't take to much time to start and configure the dependencies maybe an option would be to add them in init_per_suite (and teardown in end_per_suite). And/or in the ct_hooks themselves. Probably more code duplication but the dependencies would be configured closer to the separate tests. The ct_hooks seem also to be installable from the suite (suite/0 and init_per_suite/1) if that helps. Best Regards Mikael From raoknz@REDACTED Wed May 29 04:27:49 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Wed, 29 May 2019 14:27:49 +1200 Subject: [erlang-questions] Famous threads? In-Reply-To: References: Message-ID: spawnedshelter.com is just WONDERFUL. How did I miss it? I've been following Erlang for longer than I care to admit, and there's information there that I still needed to know. Brilliant! On Wed, 29 May 2019 at 01:42, Brujo Benavides wrote: > Hi Yestin, > > You can start with the links and references from > http://spawnedshelter.com/ > > Cheers! > > On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison wrote: > >> I'm still relatively green to all this Erlang business. Considering that >> this >> list's first message predates my birth by a few months, and seeing >> references >> to threads everywhere from recordings of Erlang talks to StackOverflow >> answers, >> I was wondering if anyone could name any sort of "required reading" as it >> concerns design philosophy, shared culture, programming style, unspoken >> guidelines, heuristics, or anything else under the sun, that may only be >> obvious to relative veterans of this list. For instance, Garrett Smith's >> "Why >> the Cool Kids Don't Use Erlang" (2014) mentions the then-recent "bikeshed >> thread" that was apparently notorious enough to warrant a survey, and I >> can't >> for the life of me dig that out of the archive. If I can compile a list of >> such things, I may well be able to upload that somewhere for others' >> future >> reference. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > > > Brujo Benavides > about.me/elbrujohalcon > > _______________________________________________ > 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 Wed May 29 04:34:20 2019 From: bob@REDACTED (Bob Ippolito) Date: Tue, 28 May 2019 19:34:20 -0700 Subject: [erlang-questions] Famous threads? In-Reply-To: References: Message-ID: Likewise! This is a great resource, would be fantastic to have it linked to from Erlang.org and elsewhere :) On Tue, May 28, 2019 at 19:28 Richard O'Keefe wrote: > spawnedshelter.com is just WONDERFUL. How did I miss it? > I've been following Erlang for longer than I care to admit, > and there's information there that I still needed to know. > Brilliant! > > On Wed, 29 May 2019 at 01:42, Brujo Benavides > wrote: > >> Hi Yestin, >> >> You can start with the links and references from >> http://spawnedshelter.com/ >> >> Cheers! >> >> On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison >> wrote: >> >>> I'm still relatively green to all this Erlang business. Considering that >>> this >>> list's first message predates my birth by a few months, and seeing >>> references >>> to threads everywhere from recordings of Erlang talks to StackOverflow >>> answers, >>> I was wondering if anyone could name any sort of "required reading" as it >>> concerns design philosophy, shared culture, programming style, unspoken >>> guidelines, heuristics, or anything else under the sun, that may only be >>> obvious to relative veterans of this list. For instance, Garrett Smith's >>> "Why >>> the Cool Kids Don't Use Erlang" (2014) mentions the then-recent "bikeshed >>> thread" that was apparently notorious enough to warrant a survey, and I >>> can't >>> for the life of me dig that out of the archive. If I can compile a list >>> of >>> such things, I may well be able to upload that somewhere for others' >>> future >>> reference. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> -- >> >> >> Brujo Benavides >> about.me/elbrujohalcon >> >> _______________________________________________ >> 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 yestin@REDACTED Wed May 29 05:17:08 2019 From: yestin@REDACTED (Yestin L. Harrison) Date: Tue, 28 May 2019 20:17:08 -0700 Subject: [erlang-questions] Famous threads? In-Reply-To: <309225388.5717484.1559053047266@mail.yahoo.com> References: <309225388.5717484.1559053047266@mail.yahoo.com> Message-ID: Thank you, all; I appreciate the sentiment. There are definitely some links on this Spawned Shelter page that weren't already in my bookmarks. :) Perhaps, though, I should clarify just how "relative" "relatively green" was supposed to mean: I'm two years and three main projects deep, and know how to operate a search engine; it's just that I haven't yet judged myself fit to "break into the industry", nor have I participated awfully much in the broader Erlang community. The most informative talks I've seen, by and large, come from 2009-2014, and my picture of where things stand gets progressively hazier after that. The sorts of questions I still end up having are: "Should I bother maintaining a makefile for libraries I intend to release or does everyone just use rebar3 now?", "If I'm writing a source-to-source compiler for a well- established DSL in the vein of `asn1ct` or `snmpc`, should I take pains to stay as consistent as possible with the various modules listed in `erl_compile`?", or "What sense do I make of all these undocumented yet invaluable functions like io:request/2?? I'm currently /specifically/ curious as to whether there are insights or bits of history hiding in the erlang-questions archive in particular, snapshots of the zeitgeist, lesser-known aphorisms from the creators, that sort of thing. I'm looking to develop my personal almanac of the Erlang ecosystem and community, as it were, so I can stop feeling that no matter how much reference material I pore over I'm still on the outside looking in, at least as it regards how other Erlang programmers actually operate today. I hope that makes sense; I understand what I'm ultimately asking is somewhat vague. On 5/28/19 07:17, Juan Mart?n Guill?n wrote: > The one Brujo is mentioning is great, I did't know about it. > > I would add Learn You Some Erlang: https://learnyousomeerlang.com/ > > And of course for the people of your generation the audiovisual and > acclaimed "Erlang: The Movie": https://www.youtube.com/watch?v=uKfKtXYLG78 > > And the sequel: https://www.youtube.com/watch?v=rRbY3TMUcgQ > > Regards, > Juan Mart?n. > > > > > El martes, 28 de mayo de 2019 10:42:19 ART, Brujo Benavides > escribi?: > > > Hi Yestin, > > You can start with the links and references from http://spawnedshelter.com/ > > Cheers! > > On Tue, May 28, 2019 at 10:36 AM Yestin L. Harrison > wrote: > > I'm still relatively green to all this Erlang business. Considering > that this > list's first message predates my birth by a few months, and seeing > references > to threads everywhere from recordings of Erlang talks to > StackOverflow answers, > I was wondering if anyone could name any sort of "required reading" > as it > concerns design philosophy, shared culture, programming style, unspoken > guidelines, heuristics, or anything else under the sun, that may only be > obvious to relative veterans of this list. For instance, Garrett > Smith's "Why > the Cool Kids Don't Use Erlang" (2014) mentions the then-recent > "bikeshed > thread" that was apparently notorious enough to warrant a survey, > and I can't > for the life of me dig that out of the archive. If I can compile a > list of > such things, I may well be able to upload that somewhere for others' > future > reference. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > > > Brujo Benavides > about.me/elbrujohalcon > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlangsiri@REDACTED Wed May 29 09:57:00 2019 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 29 May 2019 09:57:00 +0200 Subject: [erlang-questions] no more logs using logger with common tests In-Reply-To: References: Message-ID: This PR should solve the problem with relative paths: https://github.com/erlang/otp/pull/2264 tir. 28. mai 2019 kl. 12:35 skrev Siri Hansen : > Do you see any printout in the shell like > > Logger - error: {removed_failing_handler,default} > > ?? > > The log files should be created relative to your current work directory - > but when trying similar configuration as you describe it seems logger fails > pretty soon due to ct's change of current directory :( Can you try it once > with an absolute path to verify if you're facing the same problem or if > it's something else? > > Regards > /siri > > tir. 28. mai 2019 kl. 11:14 skrev Benoit Chesneau : > >> Hi all, >> >> I've switched my code to logger macros instead of using lager. But now >> I've no log stored on the filesystem ie in >> `_build/test/logs/ct_run.nonode\@nohost.2019-05-28_10.49.10/` or similar >> folder.. Any idea what could be the issue? >> >> >> >> I use following sys config: >> >> ``` >> [ >> {kernel, >> [ >> {logger_level, debug}, >> >> >> {logger, >> [{handler, default, logger_std_h, >> #{level => error, >> config => #{file => "log/erlang.log"}}}, >> >> {handler, info, logger_std_h, >> #{level => debug, >> config => #{file => "log/debug.log"}}} >> ]}]} >> ]. >> ``` >> >> ad my rebar.config: >> >> ``` >> ... >> {ct_opts, [ >> {sys_config, ["config/test.config"]}, >> >> {ct_hooks, [cth_surefire]} >> >> ]}. >> ``` >> >> Hope it helps, any idea is welcome :) >> >> Benoit >> >> _______________________________________________ >> 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 Wed May 29 21:40:52 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Wed, 29 May 2019 15:40:52 -0400 Subject: [erlang-questions] Reliable file transfer? Message-ID: <04DD2121-4889-47E5-98C7-8FFE16D20B8A@writersglen.com> Hello, I?m evaluating https://www.rsync.net/ as a possible backup/archiving service for Erlang dets and Mnesia data. rsync.net offers replicated data store on ZFS with frequent snapshots at an attractive price. Data can be transferred via rsync, SFTP, etc. My thought is to create a data management app that would automate the backup/archive/restore functions. But I don?t understand the data transfer options available in Erlang well enough to implement. The options I see are: ? calling rsync via os:cmd/1 ? seems simple enough but I?m breaking out of Erlang ? ssh-sftp ? just don?t understand how to use this library ? File Transfer Service ? docs are totally confusing???? One would think that this is an every day plain vanilla kind of problem. But there?s scant guidance on the web. Can some kind soul point me in the right direction? Many thanks, LRP Sent from my iPad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Thu May 30 11:12:56 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 30 May 2019 11:12:56 +0200 Subject: [erlang-questions] Reliable file transfer? In-Reply-To: <04DD2121-4889-47E5-98C7-8FFE16D20B8A@writersglen.com> References: <04DD2121-4889-47E5-98C7-8FFE16D20B8A@writersglen.com> Message-ID: On Wed, May 29, 2019 at 9:41 PM Lloyd R. Prentice wrote: > > Hello, > > I?m evaluating https://www.rsync.net/ as a possible backup/archiving service for Erlang dets and Mnesia data. > > rsync.net offers replicated data store on ZFS with frequent snapshots at an attractive price. Data can be transferred via rsync, SFTP, etc. > > My thought is to create a data management app that would automate the backup/archive/restore functions. But I don?t understand the data transfer options available in Erlang well enough to implement. > > The options I see are: > > ? calling rsync via os:cmd/1 ? seems simple enough but I?m breaking out of Erlang > ? ssh-sftp ? just don?t understand how to use this library > ? File Transfer Service ? docs are totally confusing???? > > One would think that this is an every day plain vanilla kind of problem. But there?s scant guidance on the web. > > Can some kind soul point me in the right direction? We're using os:cmd and rsync/scp/ssh to transfer our DB backups to internal backup servers, rsync in particular because it enables incremental transfers of our leveldb snapshots. Stuff is also pushed to S3, but that's done outside of the main Erlang transaction servers. (Erlang-based micro-services classify and redistribute event-based data, while Unix cron jobs transfer plain files.) I don't think we ever used the other options you mention. From lloyd@REDACTED Thu May 30 16:57:19 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Thu, 30 May 2019 10:57:19 -0400 Subject: [erlang-questions] Reliable file transfer? In-Reply-To: References: <04DD2121-4889-47E5-98C7-8FFE16D20B8A@writersglen.com> Message-ID: <27989590-DDC8-43E1-B8B5-B8DF6402E530@writersglen.com> Thanks, Mikael, That?s reassuring. Best wishes, Lloyd Sent from my iPad > On May 30, 2019, at 5:12 AM, Mikael Pettersson wrote: > >> On Wed, May 29, 2019 at 9:41 PM Lloyd R. Prentice wrote: >> >> Hello, >> >> I?m evaluating https://www.rsync.net/ as a possible backup/archiving service for Erlang dets and Mnesia data. >> >> rsync.net offers replicated data store on ZFS with frequent snapshots at an attractive price. Data can be transferred via rsync, SFTP, etc. >> >> My thought is to create a data management app that would automate the backup/archive/restore functions. But I don?t understand the data transfer options available in Erlang well enough to implement. >> >> The options I see are: >> >> ? calling rsync via os:cmd/1 ? seems simple enough but I?m breaking out of Erlang >> ? ssh-sftp ? just don?t understand how to use this library >> ? File Transfer Service ? docs are totally confusing???? >> >> One would think that this is an every day plain vanilla kind of problem. But there?s scant guidance on the web. >> >> Can some kind soul point me in the right direction? > > We're using os:cmd and rsync/scp/ssh to transfer our DB backups to > internal backup servers, rsync in particular because it enables > incremental transfers of our leveldb snapshots. Stuff is also pushed > to S3, but that's done outside of the main Erlang transaction servers. > (Erlang-based micro-services classify and redistribute event-based > data, while Unix cron jobs transfer plain files.) > > I don't think we ever used the other options you mention.